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Preface 



En 2000 a circule sur Internet une histoire qui s'est revelee par la suite une imbrication 
inextricable conformations vraies et de legendes. Elle peut etre resumee comme suit. 

L'ecartement standard entre les rails aux Etats-Unis est de 4 pieds et 8,5 pouces, ce 
qui est une mesure particulierement biscornue. Pourquoi cette mesure ? Parce que les 
premieres lignes de chemin de fer ont ete baties principalement par des expatries 
anglais et surement avec de la technologie et des outils anglais, les Anglais etant a 
l'epoque a la pointe de la technologie. Pourquoi les Anglais ont-ils exporte cette 
mesure ridicule ? Parce que les premiers chemins de fer ont ete construits par les 
hommes et avec les outils des fabricants de tramways sur route, et done la distance 
entre les roues de ces tramways est devenue l'entre-rails. Et pourquoi cette distance 
entre les roues des tramways ? Parce que chaque fois qu'une autre distance avait ete 
mise en ceuvre dans le passe, le tramway, ou tout autre vehicule, s'etait « casse la 
figure » a cause de profonds sillons, sortes de rails, creuses a cette distance et presents 
sur toutes les routes dAngleterre et d'Europe. Pourquoi des ornieres avec cette dis- 
tance entre elles ? Parce que ces routes avaient ete d'abord baties pour faciliter les 
deplacements des legions de l'empire remain, et les chariots de guerre remains, leurs 
principaux usagers, exhibaient une telle distance entre les roues. 

A partir d'ici, l'histoire se perd un peu, et on evoque les dimensions des posterieurs 
des chevaux pour expliquer la distance entre les roues des chariots de guerre. Quoi 
qu'il en soit, e'est a partir d'une specification des ingenieurs de l'armement de Rome 
que, au troisieme millenaire et aux Etats-Unis, la voie standard des chemins de fer est 
specifiee. L'histoire ensuite prend un tournant particulierement technologique, avec 
les dimensions des solid rocket boosters de la navette spatiale, qui seraient definies ainsi 
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parce que les SRB doivent etre transported par chemin de fer, a travers des tunnels 
dont la largeur est a peine superieure a l'ecartement des rails, de l'usine Thiokol 
(Utah) au site de lancement. . . La conclusion peremptoire est que les dimensions d'un 
des systemes de transport les plus modernes et avances du point de vue technologique 
sont determinees par la largeur des posterieurs des chevaux des legions romaines ! 

Cette histoire est une legende (http://www.snopes.com/history/american/gauge.htm, 
http://truthorfiction.eom/rumors/r/railwidth.htm), mais sa morale est edifiante : 
« Specifications and bureaucracies live forever ». En d'autres termes, nous manifestons 
la tendance forte, par conformisme (diraient les pessimistes) ou par sens pratique 
(diraient les optimistes), a garder en vie certains elements des architectures que nous 
construisons dans tous les domaines au-dela de toute attente. Ces elements ne sont 
pas materiels (on passe des chariots de guerre a la navette spatiale, en passant par les 
tramways, les chemins de fer...), mais bien immateriels : e'est des mesures, Acs for- 
mats, des protocoles, des specifications, des choses que les anglo-saxons appellent effi- 
cacement « software », ce qui ne veut pas dire simplement « code de 
programmation », mais se definit par opposition a l'« hardware », qui ne veut pas dire 
simplement « ordinateur ». C'est a premiere vue etonnant de se rendre compte que 
beaucoup de choses « soft » sont si dures a mourir, beaucoup plus que le « hard » qui 
est en dessous. Si on y refiechit, il est pourtant clair que le « hard » est materiel et 
done certainement perissable, alors que le « soft » est immateriel et done a priori 
immortel. 

Lorsque la base de donnees strategique etait le point de rencontre de toutes les appli- 
cations, son schema etait l'objet de toutes les attentions, l'enjeu fondamental de la 
maitrise du systeme d'information. A l'epoque des systemes repartis et intercon- 
nectes, du Web et des services Web, les schemas XML sont les « specifications » du 
format de l'information. La legende nous apprend que ces specifications dureront 
beaucoup plus longtemps que les machines, les reseaux, les bases, les systemes et les 
programmes qui interpretent, transportent, stockent, manipulent et presentent 
l'information. En plus, elles determineront de facon essentielle la capacite a inter- 
operer des dits systemes et programmes. 

Le livre dense et interessant de Jean-Jacques et Antoine nous fait beneficier de leur 
grande experience et competence, pour nous expliquer comment batir au mieux nos 
« specifications » de l'information. Je dis au mieux, car il est clair, et le livre insiste la- 
dessus (c'est meme son leit-motiv), que la specification parfaite est precisement et 
modestement le meilleur compromis entre exigences contradictoires. C'est pour cela 
que le metier d'architecte de l'information n'est pas facile, mais peut s'appuyer effica- 
cement sur des methodes et techniques de modelisation qui lui simplifient partielle- 
ment la vie. 
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On pourrait dire : d'accord, mes schemas ne sont pas bons, je peux les changer facile- 
ment, finalement tout cela ce n'est que du soft ! La morale de l'histoire est que les 
specifications qui s'affirment, qu'elles soient bonnes ou non, sont destinees a rester 
longtemps, car le nombre de gens qui se les approprient et batissent par-dessus 
devient vite non maitrisable et apres c'est trop tard. Cette vitesse devient foudroyante 
lorsque les systemes en question ne manipulent pas la matiere ou l'energie, mais 
rinformation et, en plus, sont immerges dans l'economie de reseau, a i'interieur 
comme a l'exterieur de l'entreprise. Les specifications, soumises a l'« effet reseau » 
(plus on les utilise, plus elles deviennent interessantes, independamment de leur qua- 
lite, et on les utilise encore plus car elles sont interessantes) deviennent inevitable- 
ment des verrouillages {lock-in). La qualite des specifications n' allonge pas leur vie, 
mais diminue l'inconfort et la fatigue des usagers et des developpeurs, ce qui devrait 
etre considere par tout professionnel comme un objectif de nature deontologique. 

Que le lecteur ne se trompe pas : la qualite des modeles et des schemas XML est 
beaucoup plus importante, par son incidence sur les systemes d'information, que 
toute architecture materielle, logicielle, de processus, car ces dernieres peuvent etre 
beaucoup plus facilement modifiees, adaptees, remplacees. Done, si Ton doit choisir, 
c'est la qu'il faut dedier la plus grande attention et l'ouvrage de Jean-Jacques et 
Antoine est le livre de chevet de celui qui en a la lourde tache. 
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Avant-propos 



Une rencontre fortuite entre ses deux auteurs participe de la genese de cet ouvrage. 
Le hasard a fait que nous soyons mis en presence un soir, l'un parlant de UML, 
l'autre de XML. Notre echange a mis au jour le vide qui existait entre la realite et les 
discours de salon : contrairement aux idees recues, utiliser UML pour concevoir des 
modeles XML n'est pas direct, et confrontees a la specificite de XML, les anciennes 
methodes de modelisation semblent echouer. Nous avons eu envie de clarifier la 
situation au moyen d'un ouvrage. Levidence du probleme s'est revelee encore plus 
des que nous avons commence a rediger l'ouvrage ; nous n'imaginions pas a quel 
point notre intuition initiale etait en deca de la realite. 

Chacun dans sa specialite a vu ses idees converger avec celles de l'autre ; cela s'est fait 
dans l'harmonie. C'est important. Comme Marcel Dassault, qui disait souvent 
qu'« un bon avion est un bel avion », nous pensons qu'un bon modele est un beau 
modele. 

Faute de pouvoir tout connaitre des applications de XML, nous etions certains d'au 
moins une chose : XML est bien plus qu'un nouveau format d'echange de donnees 
entre ordinateurs, bien plus qu'un alignement de balises et d'attributs. C'est un nou- 
veau type de modele de donnees qui, a ce titre, doit recevoir de nouvelles techniques 
de modelisation. 

XML est pour les ordinateurs une nouvelle langue universelle qui va peut-etre enfin 
leur permettre de s'ouvrir a la communication. Une langue qui serait toutefois 
aujourd'hui comme folle, parlee par mille personnes qui ne chercheraient ni a 
s'ecouter, ni meme a apprendre la langue de son interlocuteur. Limage est caricatu- 
rale mais l'impression generate laissee par l'avalanche de normes, standards et proto- 
coles XML y confine parfois. 
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Les possibilites de la matiere XML sont encore sous-estimees. Le basus XMLius ne 
fait que decouvrir la puissance reelle de XML, qui va bien au-dela d'un simple 
format d'enregistrement. Voyez un peu : on exprime en XML des structures de don- 
nees, des documents pourtant usuellement assimiles a des donnees non structurees, des 
descriptions de processus, des ressources informatiques physiques, mais egalement 
des concepts totalement abstraits, des langages de programmation, et la liste est 
encore longue... XML pourrait meme envahir sous peu les couches basses des sys- 
temes d'exploitation. 

Une telle omnipresence ne peut qu'inciter les concepteurs d'applications a com- 
prendre, bon gre mal gre, comment toutes ces architectures de donnees et d'informa- 
tion s'integrent et cohabitent. XML permet de manipuler des espaces d'information 
a n dimensions. Au cceur d'applications de plus en plus interconnectees, les donnees 
XML, de par les enjeux economiques qu'elles representent, devront etre modelisees 
avec le plus grand soin. 
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Comme tout langage, XML a ses regies et, comme toute creation humaine, il 
n'expose sa puissance qua ceux qui le lui demandent. 

Nous esperons repondre dans cet ouvrage a de nombreuses questions, a commencer 
par une explication du vocabulaire qui s'y trouve utilise. Diverses influences font que 
des termes abscons sont trop souvent utilises par les specialistes : nous voulons les 
rendre aussi simples a comprendre que possible. Ces mots doivent, comme frigidaire, 
devenir courants. C'est ce souci de clarte, de simplicite, qui nous a guides tout au 
long de cet ouvrage. 

Au-dela de la theorie, nous mettons notre experience a votre disposition : d'un cote, 
dix annees de modelisation, et de l'autre, vingt ans de SGML et XML. Cette expe- 
rience nous autorise a formuler quelques conseils dans le choix des modeles et de la 
methode. Ceux que nous presentons ont tous ete confronted a des projets reels. 

Ce livre apporte des reponses aux questions suivantes : Quel est le bon modele ? 
Comment concevoir un modele ? Existe-t-il une methode ? Comment mettre au 
point les schemas XML ? Comment mesurer la qualite d'un modele ? 

Un schema XML est la traduction physique d'un modele. Nous expliquons ici com- 
ment conduire la conception d'un tel modele. Nous decrivons les differentes etapes 
qui permettent de passer du modele theorique au schema concret. 
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Peu a peu, la prise de conscience se fait que XML a un role a jouer bien plus grand 
que celui de simple format de fichier. Cet ouvrage est destine tant a ceux qui en sont 
convaincus qua ceux qui decouvrent la modelisation XML. 

Ayant aboli les frontieres traditionnelles de la donnee structuree, du document et de 
la transaction, XML s'est impose de facto comme modele universel dans la definition 
de schemas de stockage des donnees (XML Schema et Relax NG), d'echange 
(SOAP, UDDI, WSDL), ^application de regies metier (XSLT, XQuery, Schema- 
tron) et d'orchestration des processus (BPEL). 

Au regard des couches logicielles qui composent les systemes d'information apparait 
naturellement le concept d'architectures de donnees. Lempilage des couches de don- 
nees va confronter les concepteurs a un probleme du type tour de Babel. On le voit 
deja avec des applications telles que SOAP et JSP qui permettent de faire cohabiter 
dans un meme fichier informatique plusieurs modeles XML, voire plusieurs langages 
de programmation. 

C'est a ce stade que XML devient un outil de modelisation, passant du statut de 
simple descripteur de donnees (le schema des donnees) a celui de chef d'orchestre (le 
schema des processus qui le fontvivre). 

La question de la representation des nouveaux systemes n'a pas de reponse officielle. 
II hexiste pas a ce jour de methode de modelisation des systemes qui aurait ete spe- 
cialement etudiee pour XML. Cela viendra probablement un jour, mais le travail est 
difficile : XML est multiforme, la « chose » est plus complexe qu'il n'y parait. Si 
l'information est la plus humaine des caracteristiques animales, sa gestion avec XML 
est la plus humaine des creations de l'informatique. 

Nous cherchons desormais a representer des flux d'informations qui, par nature, ont 
pour vocation a circuler, s'echanger, se transformer. XML est aujourd'hui la seule 
reponse que nous ayons face au besoin grandissant de gestion d'informations chan- 
geant d'etat continuellement. Nous en tenons compte ici des le chapitre 1. 

Aussi, produire des schemas XML ne se limite pas a ecrire des schemas statiques de 
donnees mais a representer les differents etats de l'information, de sa creation a son 
obsolescence. 

Concretement, vous allez decouvrir : 

• une demarche de modelisation XML en utilisant UML ; 

• les impacts de XML sur la conception des systemes d'information ; 

• les trues et astuces de certains schemas XML. 
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A qui s'adresse cet ouvrage ? 



« On comprend mieux nos ignorances d'avant » (temoignage d'un chef 
de projet ayant participe a un cours sur la modelisation XML). 

Le livre s'adresse a ceux qui, pour concevoir des systemes d'information, doivent 
recevoir, gerer et traiter des volumes importants de donnees XML. Aujourd'hui, ils 
se heurtent a des techniques de conception inadaptees au XML. Ce livre leur offre 
les explications dont ils ont besoin pour adapter leurs methodes de conception aux 
cas auxquels ils sont confrontes. 

Tous les informaticiens sont concernes par cet ouvrage. 

Nous pensons tout d'abord aux etudiants en informatique qui ne manqueront pas 
d'etre confrontes, des leur entree dans la vie professionnelle, a des projets faisant lar- 
gement appel a XML. 

Ensuite, nous pensons a ceux pour qui le XML etait initialement dedie : les deve- 
loppeurs de sites de commerce electronique et, plus largement, ceux qui concoivent 
et developpent des applications de gestion de contenu. 

Bien sur, sont egalement concernes les developpeurs de systemes de gestion et pro- 
duction de documents techniques, juridiques ou autres. 

Enfin, viennent les informaticiens du monde de la gestion qui evolue rapidement 
vers une informatique d'entreprise et, de ce fait, ouvre ses applications a la gestion 
des documents d'entreprise. 



Sujets couverts par cet ouvrage 



Ce livre fournit theorie et pratique : 

• Les sept premiers chapitres sont autant d'etapes de la demarche de modelisation 
que nous expliquons. 

• Les six suivants sont des exemples concrets de cas particuliers. 

Dans notre introduction, nous revenons sur la dualite XML/UML avec des explica- 
tions sur les concepts qui se cachent derriere les termes de modele et de schema. 

Dans le chapitre 1, nous presentons une methode de preconception d'application. 
Elle permet d'identifier, organiser et analyser les fonctions du futur systeme d'infor- 
mation. Cette methode d'ebauchage se veut simple mais efficace. Elle offre aux chefs 
de projet qui la pratiquent la possibilite de rationaliser leur projet. 

Dans le chapitre 2, nous analysons les modeles conceptuels des deux mondes XML 
etUML. 
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Dans le chapitre3, nous expliquons comment passer du modele conceptuel UML a 
un schema XML. Nous y detaillons l'utilisation de la notation graphique du dia- 
gramme des classes de UML en vue de la production d'un schema XML. 

La realisation d'un modele physique constitue le chapitre4 ou nous exposons les 
specificites du stockage de documents XML. C'est ici qu'intervient la possibilite de 
prendre en compte les mecanismes de liaison de XML. 

Dans le chapitre 5, qui traite de la separation des donnees et des traitements, nous 
expliquons pourquoi l'approche dite par objets metier n'est pas bonne ; nous lui 
opposons en effet celle orientee service, plus conforme aux fondamentaux de XML. 

Dans le chapitre 6, nous nous attractions a la problematique des variantes. A partir 
d'un modele de base, il est frequent de devoir developper des variantes. Ce chapitre 
expose tout ce qu'il faut savoir sur l'ecriture de telles applications. 

Le chapitre 7 est fondamental. Comme nous l'avons vu en introduction de cet avant- 
propos, un fichier-programme peut contenir aujourd'hui jusqu'a quatre ou cinq lan- 
gages de programmation differents ! II faut savoir representer ces programmes dans 
differents plans logiques pour s'assurer de leur coherence. 

Le chapitre 8 est le premier d'une serie traitant de cas reels. Les modeles choisis ont 
tous une originalite. lis peuvent servir d'exemple. Dans ce chapitre, nous presentons 
les modeles modulaires qui sont articules et peuvent etre decomposes en petits mor- 
ceaux. 

Dans le chapitre 9, nous expliquons le role des elements purement structuraux, qui 
sont aux schemas XML ce que les articulations sont au corps humain. 

Le cas des modules d'information est traite au chapitre 10. Nous fournissons en par- 
ticulier les regies de base qui gouvernent la conception de systemes bases sur le prin- 
cipe des modules d'information. 

Les metadonnees, qui font le pont entre la gestion du contenu et celle du contenant, 
sont presentees au chapitre 11. Les modeles RDF, Dublin Core, xHTML et 
S1000D sont presentes accompagnes de nombreux exemples concrets. 

Les possibilites de liaison sont un point fort de XML. Sans les liens, le Web ne serait 
pas, a coup sur, ce qu'il est devenu aujourd'hui. C'est un sujet important mais com- 
plexe. Nous revenons dans le chapitre 12 sur les modeles ID/IDREF, XLink, 
XPointer, XTM, et expliquons en detail le principe des liens logiques. 

Nous terminons notre voyage dans le monde des cas reels avec le chapitre 13 qui 
aborde la question de la gestion des revisions. Garder la trace et l'historique des 
informations modifiees est aujourd'hui un imperatif pour de nombreuses 
applications ; mieux vaut connaitre les possibilites offertes par XML dans ce 
domaine. 
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Quelques regies de lecture de I'ouvrage 

Les chapitres de I'ouvrage sont relativement independants les uns des autres. Vous 
pouvez done les aborder librement. Chacun d'entre eux cerne un des aspects du sujet 
general de I'ouvrage, de la facon la plus didactique possible, etayee par moult exem- 
ples et illustrations. 

L'ouvrage contient des extraits de schemas XML, des exemples de documents XML 
et des figures. Les tableaux sont egalement utilises pour presenter certains cas de 
figure. La syntaxe des schemas XML fait que les codes sources sont longs et penibles 
a lire. Parfois, nous avons prefere simplifier la lecture des schemas sources en les ecri- 
vant sous la forme DTD ou de representations graphiques. 

En ce qui concerne le vocabulaire, nous utilisons la terminologie suivante : 

• Apres avoir tres longtemps combattu le mot « parseur » au profit de la seule 
expression consacree d'« analyseur lexico-syntaxique », il apparait que le mot 
« parseur », largement utilise, s'impose. II faut lui reconnaitre l'avantage de la con- 
cision. Attention toutefois, ce mot est souvent galvaude. Nous vous encourageons 
a vous referer au glossaire pour connaitre sa definition exacte. 

• Le terme de schema pour XML est utilise pour designer un schema conforme a la 
recommandation XML Schema du W3C. Pour la norme ISO Relax NG, nous 
parlerons de grammaire. Le terme DTD est utilise pour parler d'un schema con- 
forme a la norme ISO 8879, a savoir SGML, ou la recommandation XML 1.0 du 
W3C. Pour eviter de devoir preciser le type de schema dans les cas ou cela nest 
pas utile, nous parlerons simplement de schema. 

• Nous utilisons le terme d'« instance » pour designer un ensemble d'information 
SGML ou XML valide par rapport a une DTD, et l'expression de « document 
XML » pour un ensemble d'information XML valide par rapport a un schema 
XML. 

Les premiers chapitres se lisent Fun a la suite de l'autre, mais ceux de la deuxieme 
partie de I'ouvrage peuvent etre lus dans n'importe quel ordre. 



A propos des exemples 

Nous nous interdisons de developper des theories sur des exemples imaginaires. II 
existe un gouffre entre la realite et les sempiternels exemples de bons de commandes, 
bibliotheques virtuelles et autres recettes de pizza al dente dont la litterature tech- 
nique nous abreuve. Proposer un ouvrage sur la modelisation XML qui ne serait pas 
l'image la plus precise de la realite serait une demarche de facto pervertie. Toutefois, 
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nous sommes parfois obliges de faire l'impasse sur ce principe et d'avoir recours a des 
exemples figures. lis sont alors la plupart du temps simplement detournes de cas 
reels. 

Notre politique sur cette question est nette. En accord avec Kant qui s' attache a la 
maniere dont les chercheurs font l'acquisition de leurs connaissances scientifiques, 
nous pensons que le veritable savoir ne s'acquiert que par la confrontation de postu- 
lats a la realite. 

« Avec XML, je sais travailler pour les generations futures, 
c'est du developpement durable ! » 

Jean-Jacques Thomasson 

« XML ouvre de nouveaux horizons encore inexplores 
a Implication des techniques de modelisation » 

Antoine Lonjon 
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« Un document est un ensemble d'informations selectionnees, 

assemblies et organisees pour permettre a un utilisateur 

donne de remplir une mission donnee » 

Reference : « Guide pour la realisation de specifications 

d'elaboration de documentation structuree » - 

juin 1991 - Direction Generale de I'Armement. 



Cette definition de 1991 est plus que jamais d'actualite. Initialement destinee aux 
seuls documents sur papier, elle convient aux fichiers XML, qu'ils representent des 
documents papier, electroniques, ou des donnees. En particulier, on comprend que 
cette definition convienne parfaitement bien aux fragments XML echanges entre 
systemes par le biais des services web : seul le mot « utilisateur » devrait maintenant 
etre remplace par 1' expression « utilisateur ou systeme ». Desormais, tout fichier 
XML bien forme est appele document, plus precisement document XML. On ne fait 
plus la difference entre donnees et documents, la frontiere etanche qui existait entre 
ces deux mondes est abolie et Ton devrait meme bientot simplement utiliser le mot 
Infoset, ou ensemble d'information. 

Pour les informaticiens, il s'agit d'un changement radical de perspective, d'une revo- 
lution importante qui bouleverse jusqu'a la conception des applications. 
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VOCABULAIRE Infoset et document XML 

Infoset signifie litteralement Information Set, soit en francais ensemble d'information. La recommanda- 
tion du W3C, XML Information Set, datee du 24 octobre 2001 , donne une definition abstraite de tous les 
types d'objets dont la presence est autorisee dans les documents XML. Ensemble d'information est done 
la designation la plus generale que Ton puisse donner a un document XML. 

Est baptise document XML tout fichier contenant des donnees balisees conformement aux regies definies 
par cette recommandation du W3C. Le mot document n'est done pas ici a prendre dans son sens commun. 



Nous donnons les cles de ces changements dans cet ouvrage, en termes sobres le plus 
souvent, et en ayant epure notre vocabulaire des effets de mode nefastes a la 
reflexion. Nous cherchons a presenter des invariants, pas des courants passagers. 

Modeles et schemas doivent, par definition, garantir la stabilite dans le temps : les 
applications informatiques concernees par cet ouvrage sont faites pour durer aussi 
longtemps que les organisations qu'elles servent. 

Graver les choses dans le marbre de la modelisation ne revient toutefois pas a rigidi- 
fier. Et meme bien au contraire, modeliser est synonyme de prevision et anticipation. 
Ouvrir largement les systemes informatiques est de nos jours un imperatif : extensi- 
bilite et adaptabilite sont les maitres mots de l'integration. 

Sur ce point, XML est precisement une bonne reponse au defi technologique ne de la 
mondialisation des organisations et du commerce. Ne devant en aucun cas etre reduit 
au simple role de technique de balisage, XML est un veritable type de structuration de 
l'information qui vaut modele. C'est le candidat ideal des systemes d'information de 
demain : au niveau de la memoire ou Ton retrouve les donnees, des liens qui forment 
l'information, et enfin des traitements qui rythment son fonctionnement. 

La mise en musique de ces differentes facettes de XML ne peut se faire sans rationa- 
lisation du probleme de modelisation des systemes d'information ; cela est le projet 
meme de cet ouvrage. 



Pourquoi des modeles ? 



« S'il te plait, dessine-moi un mouton ! » 

Le petit prince — Saint- Exupery 

Les modeles representent une version simplifiee mais synthetique de la realite. Le 
premier objectif d'un modele est de faire progresser la comprehension d'un domaine 
etudie. Le modele est le plan ou la carte qui permet aux acteurs d'un projet de com- 
muniquer et echanger sur la base d'une representation commune, et acceptee de tous, 
des idees du projet. 
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Un modele represente ce qu'il faut reproduire. Le mot est ambigu. L'acte de repro- 
duction peut recouvrir l'idee d'une reproduction a l'identique. Aussi, les modeles 
peuvent-ils avoir une seconde fonction qui s'apparente a celle d'un moule. Cela est 
vrai tant pour le modele du peintre et le moule en cire du fondeur que pour le deve- 
loppeur qui doit suivre un modele decrivant des donnees et fonctions. Toutefois, 
n'oublions pas de penser tout simplement a la nature humaine pour qui la reproduc- 
tion n'est pas la fabrication d'une copie a l'identique ! 

Ainsi, un modele peut tout aussi bien etre une chose du monde reel (le modele d'un 
peintre est par exemple un etre vivant ou des fruits sur un plateau...) que pure crea- 
tion (les plans d'une nouvelle construction). 

II est important de distinguer ces deux modes d'utilisation des modeles. On peut 
toujours utiliser un modele pour representer le domaine etudie, mais on ne s'en sert 
pas systematiquement comme moule. Dans le contexte de l'analyse des systemes 
d'information, cette distinction est cruciale et ne pas la faire est source de nom- 
breuses incomprehensions. Par exemple, on peut concevoir un modele de donnees 
des contrats d'assurance pour comprendre le monde de l'assurance - les contrats, les 
avenants, la reglementation - ou pour produire l'organisation exacte de la base de 
donnees correspondante. Dans les deux cas, le niveau de detail et de preoccupation 
sera different. De meme, on peut chercher a decrire les consignes de production des 
manuels de formation des nouveaux arrivants ou les processus tees complexes des 
operations de traitement des dossiers de credit immobilier. 

La modelisation est une technique qui peut s'adresser a tous les pans de l'activite 
humaine. Dans cet ouvrage, le domaine etudie est celui des systemes d'information, 
et plus particulierement celui de la representation des donnees. On peut done y 
reperer deux niveaux de preoccupation : l'un est celui de la modelisation elle-meme, 
l'autre de ses applications au domaine du traitement de l'information. 

La question des modeles n'est pas specifique a XML : « Le choix est toujours le meme. 
Soit vous rendez voire modele plus complexe et plus fidele a la realite, solt vous le rendez 
plus simple et plus facile a manipuler. Seul un scientifique naif peut penser que le modele 
parfait est celui qui represente parfaitement la realite. Un tel modele await les memes 
inconve'nients qu'un plan aussi grand et detaille que la ville qu'il represente, un plan indi- 
quant chaque pare, chaque rue, chaque batiment, chaque arbre, chaque poteau, chaque habi- 
tant. Si un tel plan etait possible, sa precision irait a I'encontre de sa destination premiere : 
generaliser et resumer. Les cartographes soulignent ces caracteristiques aupres de lews 
clients. Quelles que soient lews fonctions, les cartes et les modeles doivent tout autant sim- 
plifier le monde que le reproduire. » Extrait de La Theorie du chaos. 



CO La Theorie du chaos - Vers une nouvelle science, James Gleick, editions Flammarion, traduction 
de 1989, ISBN 2-08-081 21 9-X. 
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UML et XML : un duo gagnant 



La tentation commune a toute activite de modelisation est la recherche de l'universa- 
lite, du modele a tout faire : des lors que Ton a un marteau, tous les problemes doi- 
vent avoir une tete de clou. Cette attitude a deux consequences majeures sur 
l'approche par les modeles : 

• En etendant indefiniment leur champ d'application, elle rend impossible la defi- 
nition d'un perimetre clair de ce que decrivent les modeles en question. On ne 
sait plus de quoi parle le modele puisqu'il veut couvrir le Tout. 

• Elle conduit a confondre les modeles avec la realite : la carte n'est pas le territoire. 
Une telle confusion peut entrainer bien des desillusions lors du passage a la pratique. 

On retrouve souvent cette attitude dans 1'utilisation d'UML dont on confond le 
« U » de Unified avec celui de Universal. Certains modeles XML n'echappent pas 
non plus a cette tentation. Complet, le modele DocBook cherche a couvrir un peri- 
metre trop vaste et trop complexe (ecrit en XML Schema, le modele fait 
8 500 lignes) pour etre veritablement efficace. II en est reduit a servir de catalogue a 
tout faire, jamais ignore, jamais totalement mis en oeuvre, soit exactement le con- 
traire des souhaits initiaux de ses concepteurs. 

La tendance a l'elargissement est d'autant plus marquee dans l'informatique que nous 
venons d'un monde centralise ou donnees, traitements et communications etaient con- 
centres sur un ensemble d'applications regentees par un seul et meme environnement. 

En explosant, les capacites de stockage, de communication et de vitesse de calcul des 
processeurs ont ouvert un vaste champ de possibilites que les modeles doivent per- 
mettre de controler. 

A epoque revolue modeles revolus ! 

En complement a ses performances physiques, XML joue, sur le plan de la concep- 
tion des donnees, le role d'un outil revolutionnaire. La capacite des donnees XML a 
porter leur propre definition independamment de tout programme est un pas decisif 
vers l'autonomie des donnees. 

Le spectre de la modelisation des donnees depuis l'expression des besoins fonction- 
nels jusqu'a la solution operationnelle necessite de faire appel a trois types de modeles 
de donnees : 

• Les modeles conceptuels expriment le vocabulaire et les concepts que Ton sou- 
haite traduire sous la forme d'une application. lis permettent d'echanger des defi- 
nitions claires et servent a fixer les limites des concepts. La plupart du temps, les 
modeles conceptuels sont exprimes sous forme graphique : un dessin vaut mieux 
qu'une longue explication. Dans notre ouvrage, les modeles conceptuels sont repre- 
sentes par des diagrammes de classe UML. 
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• Les modeles logiques decrivent les structures de donnees correspondant aux con- 
cepts. Pour XML, cela se traduit par la structure arborescente des elements. Le 
modele logique sera represente pour XML par une DTD ou un schema XML, et 
pour UML par un diagramme de classe adapte a XML. 

• Les modeles physiques expriment les choix retenus pour l'implementation tech- 
nique des donnees : il se peut que les modeles logiques soient decomposes, que le 
modele de stockage differe du modele logique, que des liens differents de ceux du 
modele conceptuel soient etablis. Les documents XML eux-memes peuvent etre 
stockes selon differentes techniques (systemes de fichiers, bases de donnees...). 

Alors que XML ouvre de nouvelles possibilites, les methodes de modelisation classi- 
ques hen tiennent pour autant pas compte. Elles n'integrent pas les specificites de 
XML dans leurs considerations. Cet ouvrage apporte, en ce qui concerne UML, une 
methode pour utiliser UML afin de concevoir des schemas XML. 

UML et les differentes vues d'un systeme d'information 

Les systemes d'information ont vocation a communiquer des donnees apres les avoir 
de-stockees, transformers et transmises. Ainsi, leur analyse montre qu'ils s'articulent 
autour de trois composantes : le stockage, le traitement et la communication. En 
d'autres termes, on ne peut parler d'information qua partir du moment ou des don- 
nees sont selectionnees, assemblees, mises en forme et transmises. Voila une 
periphrase parfaite de la definition ecrite en debut de chapitre. 



Figure 1-1 

Les trois composantes d'un 
systeme d'information 




Le sujet qui nous interesse au premier chef dans cet ouvrage est celui de la definition 
et de la representation de la structure des donnees. La figure 1-1 montre que cette 
composante est a la fois proche et indissociable des deux autres. Pour etre transmise, 
une information doit etre extraite d'un systeme et transformed ; les traitements alors 
effectues ont un impact sur sa structure, et reciproquement. Une information mal 
structuree rendra difficile une execution normale des traitements et toute structure 
induira un certain type de traitement. 
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A cela s'ajoutent deux points de vue sur l'information : le premier est relatif aux pro- 
cessus informatiques qui la traitent et le second a l'organisation humaine qui i'utilise. 

Les deux sont difficiles a faire coincider. Dans la pratique, faire evoluer une organisa- 
tion humaine peut s'averer plus complique que ce ne Test pour un systeme informa- 
tique. . . et vice versa, selon les cas. 

Ainsi, la modelisation d'un systeme d'information se ramene bien souvent a faire 
coller differentes pieces d'un puzzle animees de forces antagonistes. La figure 1-2 
represente ce probleme consistant a faire tenir une grande boite dans une petite. 



Figure 1-2 

Le systeme informatique est 
forcement une vue reductrice 
d'une organisation humaine 



Correspondances 




Transformations 



Quand l'organisation humaine touche des milliers voire des millions de personnes 
avec des ramifications dans des centaines de pays, la modelisation du systeme 
s'impose. En permettant de garder la maitrise de la representation du systeme, elle 
ouvre la voie a la mise au point d'evolutions, d'extensions, de modifications. 

La modelisation est alors percue comme l'outillage de base du pilotage des projets 
informatiques. Dans ce contexte, ses domaines d'application sont aussi varies que 
l'analyse des exigences, de l'organisation, des objectifs, des fonctions attendues du 
systeme et de son architecture. Lensemble de ces disciplines est generalement appele 
architecture d'entreprise. II n'est pas dans la vocation d'UML de couvrir la totalite de 
ce spectre. Malgre ses mecanismes d'extension, UML s'adresse avant toute autre 
chose au domaine de la conception orientee objet. Dans cet ouvrage, UML est utilise 
pour l'analyse des donnees et la conception du modele de classe, toutes deux au cceur 
de notre sujet. S'il existe de multiples manieres d'exp loiter XML pour representer des 
donnees, le modele de classe d'UML permet de disposer d'une vue conceptuelle uni- 
fiee, et sa notation graphique est un outil essentiel des phases d'analyse. 

Le modele de classe ne represente toutefois pas la dynamique d'un systeme d'informa- 
tion. Pour cela, nous ferons appel a des techniques de modelisation proches de celles 
utilisees dans l'urbanisation des systemes d'information et les architectures de services. 
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XML au coeur des systemes d'information 

En structurant les donnees et l'information de maniere universelle, le langage XML 
s'applique a tous les domaines techniques relatifs a la gestion de l'information. De ce 
fait, XML nest pas, et de loin, cantonne a son seul stockage, comme c'est le cas du 
SQL avec le relationnel. XML est omnipresent. 

Dans la figure 1-3, nous indiquons que les applications de XML couvrent la totalite 
des trois composantes de base d'un systeme d'information : 

• Le stockage des donnees dans des bases de donnees XML (XML Schema ou 
Relax NG) en definissent les types, la classification revenant a RDF ou Topic Map. 

• La transformation des donnees et l'orchestration des processus sont des traite- 
ments exprimes en XML grace a des recommandations telles que XSLT et BPEL. 

• La communication des donnees peut, quant a elle, etre assuree par xHTML pour 
l'affichage, et la trilogie des services web : Soap, WSDL et UDDI. 



Figure 1-3 

L'applicabilite quasi 
universelle de XML 



Communication 



Traitement 
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XHTML 




Meme si chaque composant du systeme conserve ses specificites et prerogatives, un 
principe commun de structuration est mis en oeuvre : XML. Cela va permettre de 
concevoir des systemes d'information beaucoup plus performants que ceux en 
vigueur actuellement. 



Apports de XML a la modelisation 



Cette section revient sur les changements parfois importants induits par XML. Ces 
nouveautes vont le plus souvent dans le bon sens : les taches d'elaboration et de 
maintenance des modeles logiques et physiques sont rendues plus simples, rapides et 
efficaces. 
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II y a plusieurs categories de nouveautes : 

• Les unes sont intrinseques au meta-modele XML. 

• Les autres sont consecutives au travail normatif realise par l'ensemble de la com- 
munaute XML, et en particulier le W3C. 



Blablaware La communaute XML 

Nebuleuse d'experts repartis dans le monde constitute depuis une vingtaine d'annees a partir des pro- 
moteurs historiques de SGML, puis de XML. Une force particuliere les unit qui resulte de leurs convictions 
quant a la revolution que represente XML et des difficultes passees a se faire entendre. 



Reference LeW3C 

Le W3C, ou World Wide Web Consortium, est une association fondee par I'inventeur du Web, 
Tim Berners-Lee, recemment anobli par la reine d'Angleterre en reconnaissance des services rendus a la 
communaute des hommes. 



L'universalite de XML 

Cette caracteristique est sans conteste l'une des plus importantes de XML. 

L'universalite de XML provient de l'adoption d'une syntaxe simple et puissante qui 
represente un modele des plus generiques de representation des formes : une hierar- 
chie d'elements, leurs attributs et leur contenu textuel. C'est un peu comme si toutes 
les langues du monde utilisaient les memes constructions de phrases ! 

Cette forme commune a tous les documents XML n'a pas ete concue, a priori, pour 
representer les seules informations d'une base de donnees : le formalisme XML 
s' applique a une grande variete d'applications informatiques. II n'y a meme, semble- 
t-il, aucune limite. 

En cela, le langage XML est evidemment tres different du « modele » relationnel, 
confine aux seules applications de gestion. Par exemple, il est difficile de representer 
un fichier CAO (conception assistee par ordinateur) sous forme relationnelle. II en va 
de meme des documents techniques, pour lesquels le relationnel ne sait pas, sans 
contorsion, gerer l'ordre d'apparition des paragraphes ni les modeles de contenu 
mixte. On pourrait encore citer le cas de la programmation des processus. . . Tout cela 
est difficile en relationnel mais simple en XML. 

II est fini le temps ou les applications utilisaient des formats proprietaires qui ne pou- 
vaient facilement etre echanges avec d'autres applications. Les editeurs produisent 
desormais des logiciels permettant d'echanger les donnees avec d'autres logiciels via 
un format XML. Donnees et traitements sont clairement separes. 
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L'interoperabilite des documents XML 

Grace a leur syntaxe unique et universelle, les documents XML sont facilement trans- 
portables entre ordinateurs. Meme en considerant qu'il existe plusieurs vocabulaires, ou 
dialectes, les uns et les autres utilisent le meme format, la meme syntaxe, la meme 
grammaire. Aussi, quand les modeles sont eux-memes ecrits en XML, on peut dire que 
les ordinateurs parlent de concert la meme langue. 

De plus, documents et modeles XML peuvent etre lus par les humains sans aucune perte 
d'information. Les developpeurs du monde entier parlent, eux aussi, la meme langue. 

Dans ces conditions, les erreurs d'interpretation sont d'autant diminuees. Tout modele 
XML peut etre precisement discute et evalue sur le fond. 

Cela est important : en diminuant le nombre de transpositions entre representations 
logiques et physiques, XML diminue de maniere significative le temps de conception, 
analyse et pre-etude des nouvelles applications. 

Et bien plus, l'interchangeabilite entre ordinateur s'accroit avec l'arrivee de XML dans 
les couches basses des systemes d'exploitation et de communication. II existe desormais 
des infrastructures materielles de communication qui routent les messages en fonction 
du contenu XML de leur en-tete ou les transforment a une cadence industrielle. II 
s'agit des « hardware XML ». 

L'independance entre modeles et donnees 

Toutes les choses ont une forme. C'est meme grace a cette representation que nous 
communiquons sur les choses nous entourant. Quatre pieds, un plan horizontal, un 
dossier : c'est une chaise. 

On peut parler de la forme particuliere d'une chaise ou de la forme commune a un 
ensemble de chaises. On dira alors qu'il s'agit d'un modele de chaises. Cette distinction 
est cruciale. Elle permet de parler d'une chose particuliere independamment de son 
modele. II en est de meme en XML. II est possible d'ecrire un document sans avoir 
recours a un schema. Pour reprendre notre exemple precedent, il est possible de parler 
de « cette chaise » independamment du plan de toutes les chaises qui lui ressemblent. 

Linformatique a ete des l'origine concue pour capturer l'information de maniere 
reproductible. Cela a conduit a mettre l'accent sur les modeles en tant que moules. 
Ainsi, dans le monde des bases de donnees relationnelles, si Ton veut parler d'une 
chaise, il faudra d'abord creer le schema relationnel « chaise ». Ce dernier devra com- 
prendre toutes les caracteristiques possibles de toutes les chaises que Ton veut decrire. 
En d'autres termes, on ne peut pas parler d'une chose particuliere sans la faire entrer 
dans un moule. II faut done avoir prevu tous les cas possibles necessaires a la descrip- 
tion. Si par malheur le moule ne correspond plus, il faut le modifier. 
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C'est exactement ce qui se produit dans les systemes informatiques actuels, ce qui les 
rend tres rigides. Pour integrer un nouveau type de chaise, il faut modifier la struc- 
ture de la base de donnees. II se produit la meme chose avec les classes Java ou .Net. 

Avec XML, une veritable deconnexion s'opere entre le monde des choses - les docu- 
ments XML - et celui des moules - les schemas. On peut ecrire un document XML 
sans avoir jamais recours a un schema ou une DTD. On peut construire un schema 
par la suite pour valider le document. Des milliers de schemas pourraient valider le 
meme document XML. II existe meme plusieurs langages d'ecriture de schemas cor- 
respondant a differents types de validation. La deconnexion offre un facteur de sou- 
plesse inedit qui aura de nombreux impacts sur le mode d'organisation des donnees, 
sur leur cycle de vie, et done sur les traitements qui y sont associes. 

La forme des modeles XML 



VOCABULAIRE Forme 

Nous avons choisi de parler de la forme des documents et des modeles XML en reference a « document 
XML bien forme », traduction de « XML well-formed document », expression qui signifie que la syntaxe 
XML est correctement mise en ceuvre. 



En XML, les modeles sont ecrits a l'aide d'une DTD ou d'un schema. Ces langages 
ont ete concus de maniere a : 

• etre produits a partir d'un simple editeur ASCII ; 

• en permettre une mise en oeuvre immediate, sans recours a aucune transformation ; 

• dissocier le modele conceptuel des donnees de leur representation structuree sous 
forme XML (nous verrons que les deux representations sont largement 
complementaires : l'une representant la semantique des donnees pour une appli- 
cation et l'autre leur structure pratique) ; 

• ne pas meler donnees et traitements. 



VOCABULAIRE Donnees et traitements 

L'un des problemes a resoudre dans un systeme d'information est celui de la frontiere entre donnees et 
traitements : nous savons que les traitements sont consommateurs de donnees et plusieurs traitements 
peuvent consommer les memes donnees. La question est alors de savoir s'il est possible de trouver des 
structures de donnees communes a tous ces traitements. Nous verrons dans cet ouvrage que XML per- 
met de repousser cette frontiere. 
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XML Schema, Relax NG et Schematron sont l'aboutissement de la volonte d'appli- 
quer la forme generale de XML aussi bien aux documents qua leurs modeles. Ces 
nouveaux langages de modelisation permettent d'ecrire les modeles XML. . . en XML. 

Tous les programmes qui s'appliquaient au traitement des documents peuvent 
s'appliquer aux modeles. Par exemple, on peut concevoir une feuille de style XSLT 
pour transformer des modeles afin de les afficher en HTML, SVG, ou encore 
generer une documentation RTF. On peut exploiter la forme d'un document XML 
(c'est-a-dire le balisage) sans en exploiter le fond. 

C'est ainsi que XML n'impose finalement ni une methode d'ecriture de schema ni 
meme une syntaxe de conception. Libre a chacun de trouver la forme d'ecriture 
ideale a sa conception. Par exemple, la societe americaine Brixlogic a developpe des 
editeurs de processus destines aux metiers de la banque et de la finance s'appuyant 
sur les modeles metier que sont FpML, OFX, IFX et SwiftML. Cette societe pro- 
pose ainsi a ses clients des outils de modelisation parfaitement adaptes a leur metier. 

Les apports du travail de normalisation 

Une deuxieme serie d'elements positifs concernant XML reside dans le nombre de 
normes et, par voie de consequence, d'applications mettant en oeuvre le langage. 

Cela fait une tres grande difference avec ce que fut la situation avec SGML ou meme 
HTML : 

• SGML avait une richesse d'expression de modeles sensiblement equivalente a 
XML, mais mettait l'accent sur la possibilite de faire varier les syntaxes concretes : 
autant dire, les regies de base du langage. Cela lui fut fatal : avec l'arrivee d'Uni- 
code, cette caracteristique technique est devenue a la fois trop lourde a prendre en 
compte et d'un interet plus que limite. 

• HTML fut initialement percu comme une solution magique, mais dont les experts 
pointerent tres vite les lacunes : balisage non regulier et semantique pauvre, peu 
structurante et non extensible. Cela lui fut egalement fatal : HTML resta confine 
au monde de l'affichage de pages web et fut remplace par XML pour le reste. 

Les normes developpees autour de XML forment une galaxie de langages indepen- 
dants de tout vendeur de logiciel, ce qui rend le choix de XML encore plus attractif 
aux yeux des decideurs. 

On peut regrouper ces normes en trois categories : 

• La premiere est celle des normes de reference qui constituent ce que Ton pourrait 
denommer V infrastructure des modeles XML. C'est par exemple les normes XML 
Namespace, Xlink, XML Schema. Elles donnent des capacites supplementaires a 
XML pour exprimer differents types de donnees (des liens, des metadonnees, des 
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graphiques, etc.). On remarquera que ce groupe peut se subdiviser en deux : d'un 
cote, le groupe des normes ISO (Relax NG, Schematron), et de l'autre celui des 
recommandations du W3C. 

La deuxieme regroupe les normes qui utilisent XML pour manipuler des donnees 
XML. Ces normes peuvent etre apparentees a des langages de programmation. II 
s'agit par exemple des normes WSDL pour les services web, BPEL pour les pro- 
cessus metier, XSLT pour les transformations de donnees, XQuery et XUpdate 
pour les operations de stockage et de-stockage des donnees, etc. 
La troisieme categorie est celle des normes de type metier qui s'appuient sur les 
precedentes pour etablir des standards sectoriels. Elles sont le fruit du travail de 
groupes de reflexion qui etudient les modeles les mieux adaptes a leurs metiers : 
l'aeronautique, la banque, l'assurance, la sante... 

Tableau 1-1 Premiere categorie, exemples de normes de reference 



Les DTD 


Langage d'ecriture de schemas pour SGML et XML. 


PSVI 


Ensemble d'informations contenant le document XML et le schema qui le valide. 


RDF 


Definition de modeles de metadonnees. 


Relax NG 


Langage d'ecriture de schemas XML normalise par ['ISO. 


Schematron 


Langage d'ecriture de schemas XML permettant de specifier des regies metier. 


SVG 


Vocabulaire XML de representation d'illustrations en 2D. 


VRMLouX3D 


Vocabulaires XML de representation d'objets graphiques en 3D. 


Xinclude 


Inclusions de fichiers XML entre eux. 


Xlink 


Langage de liaison. 


XML 1.0 et 1.1 


Langage de structuration de I'information. 


XML Infoset 


Specification des unites d'information autorisees dans un document XML. 


XML Namespace 


Syntaxe et regies applicables au nom des modeles XML. 


XML Schema 


Langage d'ecriture de schemas XML du W3C. 


Xpath 


Langage d'adressage d'unites d'information depuis I'exterieur d'un document XML. 


Xpointer 


Langage de ciblage d'unites d'information depuis I'interieur d'un document XML. 


XTM 


Vocabulaire XML de description de liens thematiques entre ressources. 



Tableau 1-2 Deuxieme categorie, exemples de normes d'echange et de traitement 



BPEL 


Langage de specification de processus metier. 


SOAP, UDDIet WSDL 


Langages des services web. 


UBL 


Modele de documents de type commerciaux (commandes, facturation...) 
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Tableau 1-2 Deuxieme categorie, exemples de normes d'echange et de traitement (suite) 



XMI Vocabulaire de description de modeles UML. 


XSLT Langage de transformation de documents XML. 


Xquery et Xupdate 


Langage de requete de bases de donnees XML. 


WML 


Vocabulaire XML dedie aux applications WAP du telephone portable. 


xHTML 


Format d'affichage de documents dans un navigateur. 


Tableau 1-3 Troisieme categorie, exemples de normes sectorielles 


Aeronautique 


ATA 2200, S1 000D, AECMA 2000M 


Automobile 


J2008 


Audiovisuel 


MPEG 4 et MPEG 7 


Banque 


SwiftML, OFX, IFX, FpML 


Commerce 


EbXML, UBL 


Sante 


HL7 


Formation 


SCORM 



Un facteur d'adaptation des applications 

L' expansion geographique et fonctionnelle des applications informatiques a une con- 
sequence etrange : ces dernieres deviennent theoriquement susceptibles d'evoluer en 
permanence. 

L' augmentation du nombre d'utilisateurs, des cas particuliers a traiter, des systemes a 
interconnecter fait que, a l'echelle de la planete, l'environnement informatique des 
applications change constamment. 

En consequence, il est imperatif, d'une part de banaliser les couches systeme et mate- 
riel, et d'autre part de rendre plus fiexibles les couches metier... parmi lesquelles on 
va trouver les donnees. 

XML, encore lui, est pressenti comme bon candidat a l'election de « format pivot 
universel des systemes d'information ». 

L'organisation OASIS souligne bien l'importance de ce point dans l'enonce des 
avantages attendus de UBL, un vocabulaire XML quelle propose pour faciliter les 
echanges commerciaux : 

« Nous attendons de ce standard les avantages suivants : 

• Un cout plus falble d' integration, tant a I'exterieur qua I'interieur des entreprises, grace 
a la reutilisation de structures de donnees communes. 
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• Une diminution du prix des logiciels parce que developper un logiciel devant respecter 
un balisage predefini est bien plus facile qu'ecrire un logiciel reconnaissant un nombre 
illimite de balises. 

• Un apprentissage plus facile, parce que les utilisateurs ne doivent maitriser qu'une seule 
bibliotheque d'elements. 

• Une plus grande facilite d'acces a la technologie pour les PME. 

• Des formations standardises, permettant d'augmenter le nombre de travailleurs formes. 

• Le developpement d'un pool universel de competences en integration de systemes. 

On attend aussi de V adoption de UBL quelle encourage la creation de programmes peu cou- 
teux d'import/export des donnees et que ce standard fournisse une syntaxe universellement 
connue et reconnue, et quelle soit legalement associee aux documents commerciaux. » 

L'adressage 

Les capacites d'adressage sont multiples. Avec XML, on peut facilement : 

• Identifier une donnee XML : a cette fin, des mecanismes d'identification permet- 
tent de controler l'unicite d'une information. Les types ID/IDREF et les meca- 
nismes unique, key (cle) et keyref (reference de cle) de XML Schema du W3C 
sont de bons outils d'identification et de controle d'unicite. 

• Cibler une ressource a partir d'un contexte totalement etranger a XML. Les res- 
sources cibles peuvent etre identifiees par des descriptions de chemin d'acces 
absolues ou calculees. Les normes Xpath et Xpointer du W3C servent a cela. 

• Relier les donnees les unes aux autres. Tous les types de liens sont prevus en 
XML ; depuis les simples URN (composes des URL et des URI) jusqu'aux liens 
complexes Xlink ou semantique (XTM). 

• Decrire une donnee en la ciblant de maniere indirecte ou en utilisant des meca- 
nismes de rebond. Toutes ces techniques sont mises en ceuvre par les normes 
RDF et XTM (XML Topic Map), respectivement faites pour decrire des don- 
nees et gerer des liens entre elles. 

Si l'adressage est facile et offre un large eventail de possibilites, il en decoule alors 
naturellement que le stockage sera, lui aussi, grandement facilite. En fait, Fun va avec 
l'autre, a la maniere d'un miroir reflechissant : c'est aussi parce que XML a de bonnes 
capacites de stockage que le ciblage des donnees est facile. 

Le stockage 

Bien qu'il soit impossible d'eclater un document XML en une serie de repertoires et 
sous-fichiers, XML est une extension naturelle d'un systeme de fichiers. 
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Ainsi, le premier type de navigation que fait apparaitre le modele XML est la rela- 
tion parents-enfants identique a celle utilisee par le systeme de repertoires et fichiers 
de n'importe quel systeme d'exploitation. 

Une base de donnees XML donne aussi l'impression aux utilisateurs d'etre un sys- 
teme de repertoires et fichiers. Toutefois, a la difference dun systeme d'exploitation 
classique, on passe d'un fichier a son contenu de maniere continue. Les tradition- 
nelles frontieres du fichier n'existent pour ainsi dire plus. La figure 1-4 illustre ce 
propos. Ony voit des repertoires ouverts, ainsi qu'un fichier et, sous lui, une partie de 
son contenu arborescent. 



Figure 1-4 

Arborescence repertoire-fichier- 
donnee dans une base de 
donnees XML 
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Une consequence importante en est que les documents XML peuvent etre stockes 
indifferemment dans un systeme de fichiers et une base de donnees XML. Les deux 
formes de stockage sont isomorphes. Contrairement au stockage classique des don- 
nees, XML permet d'eviter toute forme de transformation des documents XML au 
moment de leur stockage et de leur de-stockage. 

Cela nous amene naturellement au dernier point de cette section, dans lequel nous 
allons aborder les qualites de XML dans le domaine de l'archivage. 
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L'archivage 



XML est issu des travaux sur SGML dont les postulats de base etaient, rappelons-le, 
les suivants : possibilite de lire les fichiers SGML indifferemment par l'homme et la 
machine, par n'importe quel ordinateur, n'importe quel systeme d'exploitation, 
n'importe quelle application. 

XML a herite des memes qualites et il en resulte que ce format de donnees est fiable 
dans le temps. II n'y a aucun risque, autre que celui de la degradation materielle, 
qu'un fichier XML cree aujourd'hui ne puisse pas etre relu dans cinquante ans. Un 
document XML n'est lie a aucune application particuliere, a aucune version de sys- 
teme d'exploitation particuliere, etc. 

Avec les bases de donnees XML (voir figure 1-4), les operations d'archivage benefi- 
cient de la grande facilite avec laquelle on peut choisir la partie de l'arborescence a 
archiver. Les documents XML a archiver sont extraits de la base de donnees et 
deviennent de simples fichiers comme le montre la figure 1-5 (l'arborescence 
exportee est la meme que celle presentee a la figure 1-4). 



Figure 1-5 

Export d'une partie 
d'une base XML vers 
un systeme de fichiers 
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Les fichiers XML ainsi exportes sont bien formes, valides, et contiennent toute 
l'information necessaire a leur exploitation presente ou future : la reference au 
modele, le type de codage des caracteres, les elements, leurs attributs et tous les 
objets autorises dans les documents XML sont presents. 

Lapplication d'archivage peut facilement lire les documents s'agissant de la recherche 
d'information (de classification par exemple) et de la determination des entites gra- 
phiques qu'il faudra potentiellement archiver avec le document. 
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Cette facilite d'export des donnees a des consequences jusque dans la conception des 
applications : ce qui est aise pour un archivage Test tout autant pour un simple 
echange de donnees. Ainsi, ces facilites d'import/export peuvent etre mises a profit 
pour alimenter, a la demande, les differents systemes constitutifs des infrastructures 
informatiques, en particulier celles qui sont reparties. 



L'expression 



Citons un dernier atout de XML, qui a des consequences non negligeables sur la concep- 
tion des systemes d'information : la capacite d'expression naturelle du balisage XML. 

Non seulement les donnees XML sont structurees les unes par rapport aux autres par 
des relations de type parent-enfant exprimant de facto une hierarchie, mais encore elles 
sont etiquetees plusieurs fois et de plusieurs manieres : 

• par le nom des elements, 

• par le nom des attributs, 

• par les valeurs des attributs, 

• par la hierarchie des noms des elements parents, 

• par le type associe aux elements parents, 

• par le jeu des identificateurs. 

On dispose done d'une reelle diversite de choix pour specifier les typologies de recon- 
naissance des donnees meme s'il revient aux concepteurs d'applications de faire les 
bons choix. 

Lapproche qui prevalait ces dernieres annees, dite par objets metier, n'exploitait 
qu'une seule des possibilites enumerees plus haut : le nom des elements. Elle etait 
notoirement insuffisante car : 

• Elle creait une relation rigide et bi-univoque entre une classe Java et une balise XML. 

• Elle ne permettait de transmettre que des types simples au sens de XML Schema 
du W3C : le contenu des elements ne pouvait etre qu'une chaine de caracteres (pas 
de transmission de structures complexes). 

• Elle ne permettait pas de gerer le contexte d'utilisation des elements. 

• Elle ne permettait pas de gerer proprement les changements de modelisation et les 
revisions des applications. 



VOCABULAIRE Objet metier 

Le principe des objets metier est d'associer automatiquement un nom d'element a celui d'une classe 
Java. Ce faisant, un programme recevant une donnee executait le programme associe sur la foi du nom 
de I'element contenant la donnee. 
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Insistons sur le fait que ces limitations sont le fruit d'une insuffisance de conception et 
ne sont en rien dues a XML, qui beneficie, quant a lui, de possibilites bien plus grandes. 

Notamment, les noms des elements XML sont porteurs d'une semantique qui peut 
etre polymorphe : puisque la hierarchie des noms d'elements forme finalement une 
suite de mots, les noms donnes aux elements peuvent changer de signification en 
fonction de l'endroit ou ils se trouvent dans cette hierarchie ; un mot pris isolement 
de son contexte n'a pas le meme sens qu'un mot « mis en musique ». II en est de 
meme avec XML. 

Par exemple, considerons I'element <1 i >, representant generalement un item de liste. 
Dans la syntaxe xHTML, les sequences <o"lx"li>, <ulxli> et <ol><u"l><"li> don- 
nent chacune des interpretations differentes de l'item de liste. 

Ce qui est evident pour une caracteristique typographique ne Test pas moins pour un 
element de donnees. Qu'il s'agisse de reconnaitre la regie typographique a appliquer 
ou le calcul a executer, le probleme est finalement le meme. 

Dans l'exemple qui suit, I'element date change de type en fonction de son contexte 
d'utilisation. II contient tantot des sous-elements (cas ©) tantot un simple texte 
(cas Qi). 

<pen'od> 
<calculation> 
<date> 

<adjustments> 
<businessDayConvention>MODFOLLOWING</businessDayConvention> 
<businessCentersReference href="#primaryBusinessCenters "/> 
</adjustments> 
</date> 
</calculation> 
<Regular> 
<f i rst> 

<date>2OOO-lO-O5</date>0 
</f i rst> 
<last> 

<date>2004-10-05</date> 
</last> 
</Regular> 

<Frequency base="Interval"> 
<Mul ti pi i e r>6</Mul ti pi i e r> 
<pe ri od>M</pe ri od> 
< roll Conventi on>5</ roll Con vention> 
</Frequency> 
</period> 
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Un programme ne devra evidemment pas traiter l'element date de la meme maniere 
selon qu'il se trouve dans le premier ou le second cas de figure. 

Pour conserver cette independance entre donnees et traitements, les noms des ele- 
ments doivent etre differents de ceux des programmes qui les traitent. Logique et 
simplicite s'imposent dans la maniere de nommer les elements, ne serait-ce que pour 
permettre a autrui de lire simplement DTD et instances... L'exemple suivant est un 
cas d'ecole de ce qu'il faut eviter de faire : 

<! ELEMENT N34 - - 

(OFFREF? , HOLREF? , DOCID , CDOCID? , H0110 , H0151 , H0180? , H0170? , H0730+ , 

H0860 , H0870 , H0880? , H0740* , H9750? , H0720? , H0280 , H0540 , H0510+ , H0270 , 

H0570? , H0820+, H0300* , H0230* , H0450? , H0152) > 

<! --<Title>Industrial design under the 1960 Act--> 

<! ELEMENT N60 - - 

(OFFREF? , HOLREF? , DOCID , CDOCID? , H0110 , H0151 , H0180? , H0170? , H0730+ , 

H0860 , H0870 , H0880 , H0740* , H9750? , H0720? , H0280 , H0540 , H0510+ , H0570? , 
H0810+ , H0820* , H0300* , H0230* , H0450? , GRAPHIC* , H0152) > 

<! --<Title>1960 Deposit (monolingual - pre 19959--> 

<! ELEMENT N600 - - 

(OFFREF? , HOLREF? , DOCID , CDOCID? , H0110 , H0151 , H0180? , H0170? , H0730+ , 
H0860 , H0870 , H0880 , H0740* , H9750? , H0720? , H0280 , 
(H054E | H054F),H0510+,(H057E | H057F)? , H0810+, H0820* , H0300*, 
H0230* , H0450? , GRAPHIC* , H0152) > 

II revient au concepteur de choisir les regies de nommage adaptees a son cas. Si 
XML offre un tees grand niveau d'adaptabilite, certains modeles peuvent neanmoins 
couter tees cher en entretien et adaptation. 

La perennite et la flexibility 

Perennite et flexibilite sont deux qualites qui correspondent respectivement a XML 
et aux schemas : 

• La perennite indique la capacite des donnees a durer dans le temps. Elle est 
garantie par XML. 

• La flexibilite represente, de son cote, la capacite des donnees a s' adapter a des 
situations imprevues initialement. Elle depend des schemas. 
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Des donnees plus perennes 

Les donnees et modeles XML sont perennes de facto pour les raisons suivantes : 

• Les fichiers XML ne sont pas des fichiers binaires : ils sont lisibles sans decodage 
prealable par l'ordinateur et un oeil humain. II n'y a done aucun risque d'erreur ou 
d'interpretation lors de l'affichage pour lecture humaine ou l'impression d'un 
fichierXML. 

• Tous les ordinateurs du monde respectent et comprennent la codification Uni- 
code des caracteres. 

• II n'y a aucun risque d'usure des fichiers avec le temps, un fichier XML ne depen- 
dant strictement d'aucune application. Le seul risque de perte de donnees avec le 
temps porte sur la partie mecanique : destruction physique de l'ordinateur ou des 
medias de stockage. Un fichier XML sauvegarde aujourd'hui restera lisible et 
exploitable aussi longtemps que ce fichier sera stocke sur un support exploitable. 

• Dans le cas le plus extreme, un fichier XML permet de stocker a la fois les don- 
nees et les explications sur les donnees : on peut meler donnees et documentation 
relative sans aucune difficulte. 

Pour toutes ces raisons, le XML s'impose (et a toujours ete recommande comme tel 
par les specialistes) comme format de stockage et d'archivage. 

Des modeles plus flexibles 

La flexibilite des systemes est du a la qualite entourant la mise au point des modeles 
de donnees. Les modeles peuvent notamment contenir des articulations qui sont des 
structures XML permettant, a la maniere du squelette humain, de donner de la sou- 
plesse aux modeles. 

En fonction des traitements a effectuer, les documents XML peuvent etre decoupes 
aux articulations. Les documents XML s'adaptent ainsi a un plus grand nombre de 
cas d'applications ; la comparaison avec le jeu de Lego™ est evidente, mais significa- 
tive. Notamment, cela permet aux documents XML de s' adapter a d'autres modeles 
de donnees et processus de traitement. La flexibilite ne se limite pas au stockage sta- 
tique des donnees, mais concerne toute la dynamique du systeme d'information. 
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En resume 



Dans ce chapitre introductif, les themes autour desquels s'articule notre ouvrage ont 
ete abordes. 

Nous avons tout d'abord introduit la notion de modele. Invitant a refiechir sur le sens 
du mot modele, nous avons rappele qu'il peut designer une representation synthe- 
tique de la realite ou un moule visant a produire une copie exacte de l'original. 

Dans le cadre de la representation du systeme d'information, il est apparu necessaire 
de disposer d'un langage de modelisation de haut niveau pour encadrer l'emploi de 
XML. UML est apparu comme le langage de reference pour la representation con- 
ceptuelle des donnees. 

Nous avons ensuite rappele les apports de XML a la modelisation, qui ont deux 
origines : l'une provenant du modele XML lui-meme, 1' autre du travail de normali- 
sation. 

D'une maniere plus generale, XML dispose de qualites intrinseques qui font de lui 
un excellent candidat pour les systemes d'information. Au travers de differentes sec- 
tions, sa facilite d'adaptation, ses capacites d'adressage, de stockage, d'archivage, 
d'expression ont ete detaillees. Et nous avons egalement fonde notre discours sur la 
perennite, la fiexibilite des modeles, et l'efficacite avec laquelle XML peut etre mis 
en ceuvre. 

Nous nous sommes attaches a montrer ce qui fait la puissance et l'omnipresence de 
XML dans les systemes d'information. Au-dela de la seule curiosite technologique, 
nous avons presente les arguments objectifs justifiant 1' organisation des futurs sys- 
temes autour de la technologie XML. 

A partir du chapitre suivant, nous allons rentrer dans le vif du sujet, en l'initiant par 
une demarche d'analyse du projet. 
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Etape 1 - La preparation 

du projet 



Comme nous l'avons souligne en introduction, XML permet d'augmenter la flexibi- 
lite des systemes d'information. Toutefois, un tel resultat ne s'obtient pas sans plan 
de travail : une methodologie adaptee est necessaire. Commen9ons done par le 
debut : la realisation d'une esquisse du futur systeme. 

Ce chapitre est consacre a ce que vous devez faire dans les tout premiers temps de 
votre projet. On pourrait appeler cette periode le projet de projet. 

Nous y expliquons comment realiser rapidement un premier degrossissage du pro- 
bleme qui se presente a vous. Cela doit vous permettre non seulement de comprendre 
le projet, mais encore de le partager avec d'autres alors que seules des idees sont for- 
mulees (a ce stade, rien de concret n'existe encore vraiment). 

Nous presentons ici la methode qui permet d'obtenir rapidement l'esquisse du projet 
en tenant compte, des le depart, de grands principes que nous expliquons au cours de 
ce chapitre. 

Inspires des methodes de conception & architectures orientees services, les croquis (ou 
esquisses) que vous obtiendrez representeront in fine les fonctions, sous-fonctions et 
services qui composeront le futur systeme. 
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Bref apercu de la methode 

Objectifs 

L'objectif est de preparer le projet : rationaliser le travail des le debut car cela se tra- 
duira finalement par un gain de temps. 

De plus, fournir des esquisses (graphiques) est efficace pour presenter le projet : 

• A sa hierarchie : rationalise, le projet n'en sera que plus convaincant. 

• Aux utilisateurs : une representation simple et comprehensible des fonctions ame- 
liorera la qualite des discussions. 

• A l'equipe de developpement : le role de chacun et les expertises attendues seront 
bien identifies. 

Ainsi, ce travail de preparation du projet va vous apporter : 

• de l'aisance quand vous aurez a parler de votre projet ; 

• de l'assurance car vous pourrez comparer differentes solutions ; 

• de l'efficacite en avancant plus rapidement qu'en utilisant les methodes classiques ; 

• la possibilite de controler la completude du systeme (n'oublier aucune fonction) ; 

• la capacite a evaluer la quantite de travail de developpement a realiser ; 

• un support utile pour organiser les developpements ; 

• une bonne maitrise des differences entre les aspects fonctionnels et techniques du 
futur systeme. 

On le voit ici, l'objectif recherche est celui de la clarification d'un probleme. 

Puisqu'elle permet d'etudier le systeme plus ou moins en profondeur (effet de zoom), 
la methode laisse la liberte de le representer de maniere plus ou moins macroscopique. 
C'est a vous de choisir, mais houbliez toutefois jamais le principe des cartes routieres : 
schematiser la realite sans la representer totalement ! (si une carte routiere etait egale a 
la realite quelle represente, elle serait aussi grande que cette realite...). Le but d'une 
telle methode est d'obtenir un schema comprehensible du futur systeme. 

La phase de preparation du projet, objet de ce chapitre, vise a vous fournir le plus rapi- 
dement possible une vue schematique des fonctions et services de votre futur systeme. 

Principes generaux 

De la donnee elementaire stockee dans une base de donnees a la page HTML, d'un 
plan de bureau d'etude a la description d'une operation de montage/demontage, des 
donnees de specification d'emballage aux documents decrivant les conditions de trans- 
port, les exemples ne manquent pas du long et permanent processus de traitement de 
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1'information. Maintes fois repete, il est toujours le meme : des informations brutes 
sont choisies pour former un ensemble info rmatif coherent qui, a son tour, est transmis 
sous la forme de documents (des informations rendues lisibles) a des personnes (ou sys- 
temes informatiques) capables de les interpreter et de les utiliser a bon escient. 

A partir de ce constat, la methode repose sur quatre principes elementaires : 

• Le processus d'extraction, assemblage et publication est invariant et caracterise 
tout systeme d'information. 

• Au sein d'un systeme d'information, le composant elementaire est un service 
capable de recevoir une information, la transformer et la transmettre a son tour a 
un autre composant elementaire. Tout composant elementaire est constitue d'au 
moins deux fonctions : l'une sert a transmettre, l'autre a effectuer un traitement. 

• Information et rigidite sont deux mots antinomiques. Le maitre mot est flexibilite'. 

• Pour faire face a la complexite du probleme, il est imperatif de pouvoir travailler 
sur des representations simples : synthetiser pour mieux comprendre. 

De maniere plus concrete, la methode met en evidence les fonctions du systeme et, 
via un mecanisme de classification et d'attribution de points, transforme une liste de 
fonctions en courbes et histogrammes explicites. 

De par l'importance quelle donne aux echanges d'information, la methode se distingue 
de celles fondees sur UML et 1' analyse des cas d'utilisation {use cases) du systeme. Ces 
dernieres cement les objets a partir des differents modes d'utilisation du systeme 
etudie, chacun etant decrit a l'aide d'un cas d'utilisation d'UML. C'est alors en 
s'appuyant sur ces cas d'utilisation que le concepteur fera emerger tres tot les principes 
de la conception orientee objet : l'encapsulation des donnees et des traitements par des 
classes. Laccent mis des le debut sur les classes contribue alors implicitement a privile- 
gier l'analyse des traitements plutot que celle des donnees echangees. La primaute 
donnee au composant objet conduit ainsi a un typage des donnees oriente traitement 
qui rend plus difficile une conception orientee vers l'autonomie des donnees echangees, 
garante de plus de flexibilite et de perennite. Lechec du deploiement a grande echelle 
des architectures d' objets distribuees a contribue au developpement des architectures 
basees sur les services ou la coordination entre les differentes unites de traitement, 
appelees « services », est realisee a l'aide d'echanges d'information. C'est ce principe 
d'analyse des echanges qui sert de base a la demarche proposee dans ce chapitre. 



Limites 



« L'uti/ite de la methode s'arrete la ou commence celle des autres », a savoir : 
• Elle n'a pas la pretention d'etre une theorie generale de la modelisation des syste- 
mes d'information. Sa seule vocation, et avantage, est d'etre simple, pratique et 
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rapide a mettre en oeuvre. Elle est limitee au travail de realisation d'une esquisse 
du futur systeme. 
• Elle ne concerne que la premiere des etapes permettant d'aboutir a la modelisa- 
tion complete du systeme. D'autres suivront d'ou sortiront, par exemple, des 
schemas XML, des modeles de traitement et de stockage. A ce titre, elle ne cou- 
vre pas les considerations relatives a la mise en oeuvre physique du futur systeme. 

Contexte ideal d'utilisation de la methode 

Cette section presente quelques definitions permettant de mieux cerner le contexte tech- 
nique et conceptuel dans lequel les resultats obtenus avec la methode sont les meilleurs. 

Un systeme de traitement de 1'information est un ensemble constitue d'une ou plusieurs 
application(s) informatique(s), capable de transformer en information des donnees 
elementaires. Delivrer cette information a des utilisateurs est sa principale raison 
d'etre, quelle que soit la forme physique choisie pour remettre cette information. 

Le terme information est volontairement utilise plutot que donnee. Nous entendons 
par information un ensemble de donnees formant une unite logique d'information. 

Une unite logique d'information est un ensemble de donnees auxquelles on a donne du 
sens en suivant une logique informative. Lunite logique d'information ressemble a un 
document, a savoir une entite ayant un sens informationnel pour l'humain qui la lit 
dans un contexte particulier. Cependant, cela peut egalement etre une partie d'un 
document : par exemple, l'ensemble des donnees composant une commande, abstrac- 
tion faite de celles concernantle destinataire de cette commande (etvice versa). 

Les donnees peuvent etre de type unitaire, documentaire ou graphique, c'est-a-dire 
qu'elles peuvent correspondre a des champs d'une base de donnees, des paragraphes 
textuels et des objets visuels. Isolee, une donnee n'a qu'un sens tandis qu'associee a 
d'autres, elle devient information et peut avoir plusieurs sens. 



Presentation detaillee des quatre principes de base de 
la methode 

Principe n°l. Un systeme d'information repose toujours sur un meme 
modele de base. 

Le premier principe de base est construit autour de l'idee que 1'information est une 
matiere vivante. A ce titre, elle a un debut, une vie et une fin : elle nait, grandit et meurt. 
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Ce cycle de vie est simple a representer. En termes techniques, le debut d'une infor- 
mation se situe dans un domaine baptise « production » tandis que sa croissance se 
passe dans un « vivier » que nous avons baptise « gestion ». Quant a sa fin, nous la 
faisons commencer des que l'information est diffusee ; en effet, elle echappe alors au 
systeme qui l'a vu naitre et passe dans un autre monde. 

C'est pourquoi la representation la plus elementaire de notre systeme d'information 
est constituee de trois zones, representees a la figure 1-1. 



Figure 1-1 

La representation la plus 
elementaire de notre futur 
systeme d'information 
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C'est a partir de ce socle que nous allons pouvoir construire une premiere representa- 
tion de notre systeme, brique par brique en suivant la demarche suivante : 

• identifier les fonctions du systeme, 

• placer chaque fonction au dessus du socle qui lui convient, 

• empiler les fonctions selon un plan (que nous allons vous presenter plus loin), 

• construire l'ensemble en pensant que chaque fonction doit rendre un service 
potentiellement independant de tous les autres. 

C'est ce dernier point qui est detaille dans le principe n°2. 

Principe n°2. Un systeme d'information est un ensemble de fonctions et 
services. 



VOCABULAIRE Service 

Selon les principes des architectures orientees service, un service est une unite de traitement autonome 
communiquant avec son environnement a I'aide de messages. 

Les services definissent ainsi des frontieres entre les lieux de traitement de l'information, I'interieur des 
services, et les lieux d'echanges de l'information - la communication entre les services. 



VOCABULAIRE Fonction 

On peut definir une fonction comme etant un traitement permettant de produire un resultat specifie a 
partir d'une entree egalement specifiee. 



Les definitions des mots « service » et « fonction » sont tres proches l'une de l'autre. A 
partir de la definition des services, on passe tres facilement a celle de fonction. En com- 
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munication, la difference entre les deux est infime. En placant la question de la com- 
munication de l'information au cceur de la problematique de conception (architecture) 
des systemes, on fait ressortir le role des services, a savoir les fonctions du systeme qui 
vont ingerer, transformer et traiter l'information recue sous forme de documents XML. 
En ce sens, les architectures orientees services et l'echange d'information (de docu- 
ments) au format XML sont deux composantes non seulement complementaires mais 
consubstantielles des systemes d'information objets de cet ouvrage. 

Vous allez voir que, grace a ce principe, on peut obtenir une bonne representation des 
echanges d'information au sein du futur systeme. La mise en valeur des communications 
entre les services appartenant aux differentes zones du socle illustre a la figure 1-1 - pro- 
duction, gestion, diffusion - met en evidence les etapes les plus significatives des diffe- 
rentes phases de traitement et d'enrichissement de l'information. Nous verrons ulterieu- 
rement qu'il existe une relation de cause a effet directe entre la qualite avec laquelle ces 
communications inter-zones sont identifiees et la flexibilite finale du systeme. Cela 
implique une relation de cause a effet directe ente la qualite de cette conception et le 
cout de developpement et maintenance du systeme final. 

Dans la figure 1-2, le systeme est represente comme s'il s'agissait d'une usine de trai- 
tement de l'information : a gauche y entrent des granules d'information, des don- 
nees, et a droite sort un produit raffine qui est bien souvent un document. 

Au dessus de la brique « production » du socle vont se retrouver toutes les fonctions 
qui servent a creer ou recuperer les granules d'information initiaux. 



Figure 1-2 
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Au dessus de la brique « gestion » seront representees toutes les fonctions d'assemblage, 
de gestion de la configuration et des processus de fabrication d'une information finie. 

Au dessus de la brique « diffusion » seront empilees toutes les fonctions permettant 
de diffuser l'information. Dans la figure 1-2, nous essayons de montrer la logique 
avec laquelle nous allons construire une representation efficace de notre futur sys- 
teme, melant petit a petit les notions de fonctions et de services. De granules blancs 
et isoles les uns des autres a l'entree du systeme, on montre comment ils sont assem- 
bles, places par rapport a un contexte exterieur dans la brique « gestion » (contexte 
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symbolise par un rectangle en pointille), puis comment ils sont adaptes a un contexte 
de diffusion (les granules blancs deviennent gris). 

Le tout respecte le troisieme principe, celui de la flexibilite, decrit dans la prochaine 
section. 

Principe n°3. Un systeme (('information est obligatoirement flexible. 

L'information, presque par definition, est en evolution permanente. Au cours du 
temps cependant, les traitements changent a un rythme encore plus rapide que les 
donnees. Ces dernieres doivent done etre organisees de maniere a assurer au systeme 
une grande flexibilite dans le temps. 



Figure 1-3 

L'information DOIT etre 
articulee et transportable. 



VALVE i,?U MPS 




Fonds 





Donnees on i ^ > Ajout de valeur on i ^ > Objet de communication 

J_ I . I 



Savoir des auleurs 



Mise en forme du fonds 
et du savoir 




Sens d'analyse du systeme 



i Publication 
< ► 



O Systeme de 

consultation 

* ► 



O Information 

elementaire 

•4 ► 




Etapes de la demarche de modelisation 

Premiere partie 



Si vous respectez le principe n°2, vous aurez a l'esprit que votre systeme manipulera 
des granules eminemment transportables alors que dans les methodes de conception 
classiques, on a plutot tendance a figer l'information dans des cases. . . 

La flexibilite d'un systeme d'information equivaut aux articulations du squelette 
humain : elle confere au systeme, non des possibilites de mouvement, mais d'adapta- 
tion de 1'information. Elle permet d'utiliser l'information a plusieurs fins, sur plu- 
sieurs medias, avec differents traitements de transformation. La figure 1-3 schema- 
tise plusieurs idees relatives a la flexibilite : 

• Le systeme doit s'adapter (en permanence) a revolution des organisations humai- 
nes. 

• Le systeme doit s'adapter aux besoins des consommateurs de l'information et de 
revolution du marche qu'ils representent. 

• Le systeme doit permettre de reutiliser une meme information, ou granule 
d'information, ou donnee elementaire. 

Enfin, la figure 1-4 schematise un autre type de flexibilite : celle du rythme des 
modifications des informations gerees par le systeme. Certaines informations ou 
donnees seront modifiees tres regulierement (des cours de bourse par exemple), alors 
que les documents qui contiendront ces donnees seront potentiellement mis a jour 
selon un rythme different. Toujours en prenant 1' exemple traditionnel des donnees 
boursieres, pensons aux documents papier contenant des analyses financieres ou les 
pages Web qui affichent les cours : on accepte la mise a jour reguliere de la page, 
mais on n' accepte pas que sa forme change continuellement. 



Figure 1-4 

Le systeme doit permettre 
de prendre en compte les 
frequences de mise a jour 
propres a chaque type 
d'information. 
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Principe n°4. La representation du systeme d'information doit etre 
synthetique et simple. 

La representation graphique du systeme repose sur des regies simples. Cela facilite la 
comparaison de differentes solutions. Cette simplicite est done un but recherche. 
Avec une representation trop complete ou trop sophistiquee, cette comparaison serait 
impossible : le seul temps passe a etablir de telles representation ferait perdre l'interet 
meme de la comparaison. Un exemple typique est celui des tarifs des operateurs de 
telephonie : a vouloir etre trop exhaustifs dans leurs tarifs, toute comparaison globale 
devient impossible ! C'est ce que nous voulons eviter avec notre methode. 

D'apres la methode, le systeme va etre progressivement decoupe en services (ensem- 
bles de fonctions de traitement) et echanges de donnees entre services. Un systeme 
simple d'attribution de points permet de noter chaque fonction et chaque service. La 
grille d'attribution des points ainsi obtenue permet d'associer un cout theorique a 
chaque solution etudiee : plus le nombre de points est eleve et plus la solution sera 
couteuse a realiser. La valeur des points aide ainsi a se faire une idee du cout de reali- 
sation du projet. 



Figure 1-5 

Courbes representant 
le systeme au terme de la 
phase d'ebauche 



Comparaison (les4solutions 




Au terme de sa mise en oeuvre, la methode produit des courbes parlantes, represen- 
tant le systeme ebauche. Par exemple, la figure 1-5 fournit le graphique obtenu au 
terme de la pre-etude d'un systeme qui devait assurer la gestion de configuration 
entre des systemes mecaniques ayant de multiples options et la documentation decri- 
vant justement lesdites options. Pour cette etude, quatre hypotheses technologiques 
differentes avaient ete retenues. Les courbes obtenues avec la methode proposee dans 
ce chapitre ont permis de comparer en un clin d'ceil le cout respectif de chacune de 



Etapes de la demarche de modelisation 

Premiere partie 



ces hypotheses. Plus precisement, la representation a permis de comprendre et dis- 
cuter chaque poste de cout, fonction par fonction, service par service. 



Mise en oeuvre de la methode 

La mise en ceuvre de notre methode se deroule en trois ou quatre phases selon la pro- 
fondeur d'analyse recherchee (figure 1-6). Dans le cas de systemes simples, l'etape 
d'analyse des services peut etre omise. Dans les systemes plus complexes, l'identifica- 
tion des services, c'est-a-dire des canaux de communication, donne le moyen de mai- 
triser les flux d'information. Cette etape devient carrement indispensable dans le cas 
des systemes complexes ayant de nombreuses interactions avec d'autres systemes. 



Figure 1-6 

Representation des differentes 
etapes de la mise en oeuvre de 
la methode 
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Au stade ultime de la methode, on peut etablir des tableaux comparatifs de diffe- 
rentes solutions techniques. En fin de chapitre, la presentation d'un cas reel en don- 
nera un exemple. 
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Etape n°l. Etablir un plan de classification des fonctions et services du 
systeme 

Comme nous l'avons aborde dans les premieres sections de ce chapitre, la definition 
la plus elementaire d'un systeme d'information est constituee des trois zones produc- 
tion, gestion et diffusion. Invariablement, le cycle de vie de toute donnee, fichier ou 
document s'inscrira dans les fonctions et services qui s'y trouvent definis. 

La zone de production regroupe les fonctions associees a la naissance de l'informa- 
tion. Cela peut etre le resultat d'une importation depuis un autre systeme, d'une con- 
version, d'une generation spontanee consecutive a un calcul, ou encore d'une action 
manuelle humaine comme la saisie d'une donnee ou d'un document. 

La zone de gestion regroupe les fonctions associees au stockage de l'information dans 
le systeme ou elle sera controlee, protegee, mise dans un processus et archivee. Cette 
zone sert a garantir la qualite et la pertinence de l'information. Pour cela, une fonc- 
tion importante de la zone est la gestion de configuration : le systeme doit permettre 
de garantir la coherence des informations les unes par rapport aux autres. 

La zone de diffusion regroupe les fonctions qui servent a preparer l'information aux 
medias de diffusion, en faire des pages HTML ou papier ou transmettre l'informa- 
tion a un autre systeme. 

Chaque zone est composee d'un certain nombre de fonctions, regroupees en blocs. 
La methode propose une serie de blocs standards, ce qui ne vous empeche pas ulte- 
rieurement d'ajouter les votres. Ceux que nous proposons sont tres utiles lors du 
demarrage de l'etude de conception d'un systeme. 

La figure 1-7 presente les blocs standards de la methode, ceux que Ton retrouve 
immanquablement dans tout systeme d'information 



Figure 1-7 

Les blocs fonctionnels 
standards de la methode 
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Pour la zone production, les blocs standards sont les suivants : 

• Importation : fonctions de recuperation des donnees d'un autre systeme, logiciel 
ou base de donnees. 

• Creation : fonctions de creation des objets de type donnee, texte, image, illustra- 
tion etc. 

• Modification : fonctions d'edition des objets crees dans les blocs creation et/ou 
importation. 

• Liaison : fonctions de pose de liens entre les objets. 

• Validation : fonctions de controle de conformite des objets deposes dans le sys- 
teme d'information. 

Pour la zone gestion, les blocs standards sont les suivants : 

• Identification : fonctions d'etiquetage des objets stockes dans le systeme. Ces don- 
nees d'identification servent la plupart du temps a retrouver, classer et gerer les 
objets contenus dans le systeme. Dans le monde des documents, les donnees 
d'identification sont souvent appelees me'ta-donne'es. 

• Protection : fonctions de controle d'acces aux objets par la definition de droits. Des 
programmes, autant que des humains, sont susceptibles d'exploiter les objets se 
trouvant dans le systeme. Les droits d'acces peuvent changer en fonction d'evene- 
ments divers : une meme personne, ou un programme, peut voir ses droits evoluer 
en fonction de la propre evolution de l'objet auquel acceder. 

• Cadencement : fonctions de definition et d'activation des processus composant le 
cycle de vie des objets, tous susceptibles d'etre soumis a des circuits de validation 
particuliers avant d'etre publies. 

• Recherche : fonctions de recherche et d'analyse des objets de la base pour en garan- 
tir l'integrite ou tout simplement les retrouver. 

• Archivage : fonction de recopie (voire destruction) des objets du systeme pour en 
faire des copies de securite ou les rendre hors d'usage tout en en conservant la trace. 

Pour la zone diffusion, les blocs standards sont les suivants : 

• Assemblage : fonctions d'agregation et collecte des objets afin d'en faire un tout 
coherent pour un media de restitution et un objectif d'information. 

• Adaptation : fonction de transformation des objets pour les adapter non seulement 
aux medias de diffusion mais encore aux lecteurs ou systemes informatiques desti- 
nataires de l'information. 

• Visualisation : fonctions d'affichage des documents obtenus par les fonctions 
d'assemblage et adaptation. 

• Transmission : fonction de transport des documents obtenus jusqu'a leurs destina- 
tions finales. 
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C'est en adaptant ce plan generique « d'urbanisation » au cas de votre propre systeme 
d'information que vous allez peu a peu le structurer et trouver ses specificities. 

Etape n°2. Identifier et classer les fonctions du systeme 

Dans les projets informatiques, il est classique d'analyser les fonctions et sous-fonc- 
tions d'un systeme. Cette etape repose tant sur les demandes des utilisateurs que sur 
le propre savoir du concepteur du systeme. En effet, si les utilisateurs connaissent 
leurs besoins, ils ne sont que rarement capables de les mettre en regard d'une logique 
informatique. II revient au concepteur de faire ce travail d'appairage. 

Pour conduire cette etape, il faut partir des demandes fonctionnelles des utilisateurs. 
On etablit alors une liste de fonctions et sous-fonctions, si possible en limitant a 1 le 
nombre de sous-niveaux de fonctions (interdisez-vous d'avoir des sous-sous-fonctions). 

Une fois cette liste etablie (le tableau 1-1 en donne un exemple), chaque fonction ou 
sous fonction est associee a l'une (et une seule) des trois zones elementaires du sys- 
teme. Dans la colonne zone, on met un P quand la fonction correspond a la zone pro- 
duction, un G quand il s'agit de la zone gestion et un D pour la zone diffusion. 

Dans le tableau, vous observerez egalement que chaque fonction ou sous-fonction se 
voit attribuer un code d'identification (FP13 par exemple pour la fonction « creer 
une structure de document en XML »). 

Le tableau 1-1 fournit un exemple du resultat a obtenir pour trois des fonctions prin- 
cipals d'un systeme. II ne s'agit que d'un extrait, un systeme reel etant compose de 
plusieurs dizaines de fonctions principales. 

A la maniere de XML Schema, qui ne fournit pas un schema universel mais est un 
outil pour creer tout type de modele, notre methode ne fournit pas une decomposi- 
tion exhaustive d'un systeme. C'est en ce sens quelle ha pas la pretention d'etre une 
theorie generale de l'architecture d'un systeme d'information. Notre methode est un 
outil pour construire votre propre representation de votre systeme : a vous d'identifier 
les fonctions principales et secondaires qui caracteriseront votre systeme selon le plan 
generique que nous fournissons et qui, quant a lui, est invariant. 

Tableau 1-1 Exemple de fonctions identifies lors d'une etude prealable de besoin 



Ref. Identification des fonctions Zone 
interne 


FP1 


Manipuler des structures de donnees et produire les fichiers XML correspondants. 






FP11 


Importer dans la base une structure de donnees definie exterieurement. 


P 


FP12 


Creer des squelettes de publication. 


P 


FP13 


Creer une structure de document en XML. 


P 
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Tableau 1-1 Exemple de fonctions identifies lors d'une etude prealable de besoin (suite) 



Ref. Identification des fonctions Zone 
interne 




FP14 


Comparer (rechercher et analyser) deux structures de donnees. 


G 


FP15 


ConnaTtre les impacts de revolution d'une structure (rechercher et analyser). 


G 


FP1 6 Creer des structures de donnees de test. 


P 


FP1 7 Modifier des squelettes de publication. 


P 


FP18 


Valider les unites d'information. 


P 


FP2 


Gerer des structures de publication. 






FP21 


Creer des modeles reutilisables de structures de publication. 


P 


FP22 


Rechercher des structures de publication. 


G 


FP23 


Controler les acces aux differentes fonctions relatives a la gestion des structures de publication. 


G 


FP3 


Manipuler des unites d'information et des graphiques. 






FP31 


Disposer d'un programme permettant d'introduire des illustrations dans la base. 


P 


FP32 


Valider les unites d'information entrant dans la base. 

Pour les unites d'information XML, il s'agit d'utiliser un parseur. En cas d'erreur, un operateur 
pourra intervenir. 


P 


FP33 


Convertir en XML les unites d'information non-XML. 
Convertir les illustrations aux standards retenus. 


P 


FP34 


Editer des unites d'information. 


P 


FP35 


Disposer d'un programme permettant d'introduire dans la base des unites d'information. 


G 









Ce travail etant fait, l'etape suivante consiste a reporter chaque fonction sur un histo- 
gramme (figure 1-8) qui va fournir une premiere representation visuelle du systeme. Ce 
placement est fait selon une logique que nous expliquons dans la suite de cette section. 



Figure 1-8 

Representation sous 
forme d'histogramme 
des fonctions du systeme 
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Les fonctions sont placees en respectant la logique suivante : 

• Le socle de base de l'histogramme represente les zones. 

• Au dessus de chaque zone sont posees les fonctions identifiees au tableau 1-1 : 
une brique par sous-fonction. Chaque colonne correspond a Fun des blocs definis 
pour chaque zone {importer, creer, modifier etc.). 

• S'il se trouve des fonctions d'interfacage entre les zones, telles que production et 
gestion, elles seront placees de part et d'autre de la ligne verticale qui separe les 
zones concernees. Lorsque cela est possible, les fonctions qui se repondent seront 
placees en regard les unes des autres. Par exemple, les fonctions FP18 {validation 
des unites d' information) et FP35 {programme d'importation des unites d'information 
validees) se correspondent dans notre exemple (en general, c'est le concepteur 
ayant etabli la liste des fonctions qui peut le dire) : elles sont done placees en 
regard l'une de 1' autre. 

• L'ordre vertical n'est pas impose par la methode : choisissez votre propre regie si 
cela permet a votre modele d'etre encore plus explicite. Vous pouvez par exemple 
les positionner en fonction de leur ordre de dependance les unes avec les autres, 
ou encore en mettant celles qui vous semblent les plus importantes en bas et en 
terminant en haut par d'eventuelles options du systeme. 

• A l'extreme gauche de l'histogramme se trouvent les fonctions d'importation dans 
le systeme tandis qua l'extreme droite sont placees les fonctions de diffusion vers 
l'exterieur. Cela permet d'avoir une comprehension rapide du graphe : a gauche 
sont representees toutes les taches necessaires pour alimenter le systeme et a 
droite toutes celles pour emettre l'information. Au centre se trouvent les fonctions 
de gestion. 

Etape n°3. Identifier et classer les services du systeme 

Cette etape concerne les systemes de bonne taille. Quand le systeme est simple, 
l'analyse fonctionnelle peut suffire et cette etape est alors inutile. 

L'analyse fonctionnelle traditionnelle ne met que rarement en evidence les interac- 
tions ayant lieu tant a l'interieur du systeme qu'entre le systeme et son environne- 
ment. En effet, cette question est essentiellement technique et non fonctionnelle. Le 
but de l'etape 3 est justement d'identifier ces interactions car elles conditionneront 
l'organisation des composants logiciels, ou services dans ce cas, du systeme. Les 
equipes techniques pourront alors developper une architecture orientee service du sys- 
teme sans perdre de vue son objectif fonctionnel. 

Les services sont des unites autonomes de traitement, coordonnees par des messages. 
lis organisent les fonctions decouvertes lors de l'etape precedente pour faire appa- 
raitre les canaux de communication du systeme. L'organisation des services, e'est-a- 



_ Etapes de la demarche de modelisation 

Premiere partie 

dire la maniere dont ils vont intervenir dans la vie du systeme, representera la 
maniere dont les fonctions interagissent entre elles, en particulier en ce qui concerne 
les donnees ou objets echanges. Les services vont ainsi devoiler un aspect tres impor- 
tant de la conception : le format, ou modele, des donnees echangees entre les fonc- 
tions du systeme. II y a ainsi une etroite relation entre les services et la conception des 
modeles de donnees. 

En complement de l'analyse purement fonctionnelle, l'identification des services 
revient a bien isoler tous les points de transformation ou d'echange d'objets (princi- 
palement des donnees ou des informations). Elle complete et organise utilement la 
liste des fonctions identifiees lors de la phase precedente. 

Une attention particuliere doit etre portee aux services situes a la frontiere entre les 
zones de production, de gestion et de diffusion. Les echanges entre ces services repre- 
sentent les points d'articulation les plus sensibles du systeme. Leur bon recensement 
est une condition requise pour 1' elaboration de scenario d'implementation de qualite. 

Etape n°4. Comparer les scenarios d'implementation 

La derniere partie de la methode va aboutir au chiffrage des differentes solutions 
d'implementation. Pour cela, nous vous proposons une demarche qui vous permettra 
d'attribuer des points aux fonctions et services identifies lors des etapes precedentes. 

Pour que l'analyse du systeme soit objective, les points seront choisis en fonction de 
criteres objectifs ! 

L'analyse va consister a donner a chaque fonction et service du systeme etudie une 
serie de cinq notes qui representent : 

1 le poids fonctionnel (l'acronyme utilise, FW, est celui de Function Weight) ; 

2 le poids logiciel (ou SW comme Software Weight) ; 

3 le poids du developpement (ou DW comme Development Weight) ; 

4 le cout du developpement (ou DC comme Development Cost) ; 

5 le cout du developpement avec prise en compte de la qualite (ou DCQ_comme 
Development Cost with Quality). 

Nous allons voir maintenant comment appliquer les notes. 

Le poids fonctionnel est une note qui vaut quand la fonction est optionnelle ou inu- 
tile, et 1 quand elle est imperative. II ne s'agit pas uniquement de mesurer par la 
l'interet d'une fonction par rapport au systeme cible, mais de faire apparaitre des dif- 
ferences entre plusieurs solutions techniques. Par exemple, il se peut qu'une fonction 
de transformation de donnees soit necessaire dans le cas d'une solution technique et 
inutile dans 1' autre. 
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he poids logiciel est une note qui peut prendre les valeurs 0, 1 ou 2. La note est attri- 
buee quand la fonction est optionnelle ou inutile et que son poids fonctionnel est 
deja 0. La note 1 est attribute aux fonctions mises en oeuvre, de base, dans la solution 
technique concernee. La note 2 signifie que la fonction n'est pas de base dans la solu- 
tion technique envisagee et doit faire l'objet d'un parametrage ou d'un developpe- 
ment specifique. 

Le poids du developpement est une note comprise entre et 3 : la note est conservee 
pour les fonctions optionnelles ou inutiles, la note 1 pour les fonctions de la solution 
etudiee, la note 2 correspond aux fonctions qui peuvent etre mises en oeuvre par un 
simple parametrage tandis que la note 3 correspond aux fonctions qui necessitent un 
developpement specifique. 

Le cout du developpement est revaluation du temps necessaire pour developper les 
fonctions dont le poids du developpement est 3. Pour les autres fonctions, la note 
correspondant au poids du developpement est maintenue. 

Enfin, le poids de la qualite est le poids du developpement augmente d'un coefficient 
qualite multiplicateur a choisir en fonction du niveau de qualite exige pour Implica- 
tion et des habitudes de votre societe sur ce point. 

Les tableaux 1-2 et 1-3, ainsi que la figure 1-9, illustrent les resultats obtenus. Le 
tableau 1-2 presente la liste comparative des fonctions identifiees pour les besoins 
d'un systeme de traitement de l'information pour lequel quatre solutions 
techniques- baptisees soil, sol2, sol3 et sol4- ont ete etudiees. Ce tableau est un 
extrait d'une etude reelle complete portant sur une centaine de fonctions. 

Les colonnes de droite du tableau contiennent les et 1 du poids de chaque fonction 
dans chacune des solutions envisagees. 

Tableau 1-2 Liste comparative des fonctions de quatre solutions 



Liste des fonctions de chaque solution 
Zone MF SF Description Soli Sol2 Sol3 Sol4 


PRODUCTION 




E1 


Importer 


FP1 1 Importer dans la base une structure de donnees definie exterieurement. 1 


1 


1 


1 




FP33 Convertir en XML les unites d'information non-XML. Convertir les illus- 
trations aux standards retenus. 


1 


1 


1 


1 


FP31 Disposer d'un programme permettant d'introduire dans la base des 1 1 1 
unites d'information. 


1 


1 


E2 


Creer 


FP1 2 Creer des squelettes de publication. 


1 





1 


1 


FP1 3 Creer une structure de donnees en XML. 


1 





1 


1 
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Tableau 1-2 Liste comparative des fonctions de quatre solutions (suite) 



Zone MF SF Description Soli Sol2 Sol3 Sol4 


GESTION 


Identif 






G1 


er 




FP35 


Disposer d'un programme permettant d'introduire des illustrations 
dans la base. 


1 


1 


1 


1 


FP41 


Gerer les unites d'information et les graphiques associes. 


1 








FP45 


Gerer les chemins d'acces aux unites d'information qui seraient stoc- 
kees a I'exterieur de la base. 


1 








G2 


Proteger 




FP23 


Controler les acces aux differentes fonctions relatives a la gestion des 
structures de publication. 


1 








FP43 


Controler les acces aux unites d'information (notion de workflow). 


1 








FP63 


Controler les autorisations d'acces aux fiches d'identite. 











FP93 


Pouvoir mettre les publications dans une zone protegee du systeme. 













G3 


Cadencer 




FP64 Gerer les processus. 


1 








DIFFUSION 


Assem 




P1 


bier 






FP71 


Produire une structure de donnees en une instance XML contenant 
I'ensemble des textes. 


1 








FP72 


Pouvoir effectuer cet export selon differents criteres de selection. 











FP81 


Pouvoir choisir parmi plusieurs formats de presentation. 












P2 


Adapter 


FP82 Disposer des convertisseurs XML->papier. 


1 








P3 


Visualiser 




FP74 


Visualiser des unites d'information ou des graphiques depuis I'inter- 
face de gestion de la base. 


1 








FP83 


Disposer d'un navigateur. 











FP84 


Prevoir un poste de controle des versions papier ou electroniques pro- 
duces. 


1 








P4. Transmettre 

















































TOTAUX 


28 


31 


36 


41 
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Le tableau 1-3 represente toutes les notes obtenues par 1'une des solutions etudiees (a 
savoir la solution 3). L'on y retrouve, pour chaque fonction : son poids fonctionnel 
(colonne FW), son poids logiciel (colonne SW), le poids du developpement 
(colonne DW), le cout du developpement (colonne DC), et enfin le poids de la qua- 
lite (colonne DCQ). 







Tableau 1-3 Tableau devaluation de la solution n 3 












Zone MF SF Description FW 


SW 


SDW 


DC DCQ 


PRODUCTION 




E1 


Importer 










FP1 1 Importer dans la base une structure de donnees definie exterieu- 
rement. 


1 


2 


3 


7 


8,89 


FP33 Convertir en XML les unites d'information non-XML. Convertir 
les illustrations aux standards retenus. 


1 


2 


3 


7 


8,89 


FP31 Disposer d'un programme permettant d'introduire dans la base 
des unites d'information. 


1 


2 


3 


5 


6,35 


E2 


Creer 








FP1 2 Creer des squelettes de publication. 


1 


1 


1 


1 


1,27 


FP1 3 Creer une structure de donnees en XML. 


1 


2 


3 


3 


3,81 


GESTION 




G1 


Identifier 










FP35 Disposer d'un programme permettant d'introduire des illustra- 
tions dans la base. 


1 


2 


2 


2 


2,54 


FP41 Gerer les unites d'information et les graphiques associes. 


1 


1 


1 


1 


1,27 


FP45 Gerer les chemins d'acces aux unites d'information qui seraient 
stockees a I'exterieur de la base. 


1 


1 


1 


1 


1,27 


G2 


Proteger 


FP23 Controler les acces aux differentes fonctions relatives a la ges- 
tion des structures de publication. 


1 


2 


2 


0,5 


0,635 


FP43 Controler les acces aux unites d'information (notion de workflow). 


1 


1 


1 


0,5 


0,635 


FP63 Controler les autorisations d'acces aux fiches d'identite. 


1 


2 


3 


3 


3,81 


FP93 Pouvoir mettre les publications dans une zone protegee du sys- 
tem e. 

















G3 


Cadencer 








FP64 Gerer les processus. 


1 


1 


1 


0,5 


0,635 


DIFFUSION 




P1 


Assembler 


FP71 Produire une structure de donnees en une instance XML conte- 
nant I'ensemble des textes. 


1 


1 


1 


1 


1,27 
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Tableau 1-3 Tableau devaluation de la solution n 3 (suite) 



Zone 


MF SF Description FW 


SW 


SDW DC 


DCQ 






FP72 


Pouvoir effectuer cet export selon differents entires de selec- 
tion. 


1 


2 


3 


3 


3,81 


FP81 


Pouvoir choisir parmi plusieurs formats de presentation. 


1 


2 


3 


3 


3,81 


P2 


Adapter 




FP82 Disposer des convertisseurs XML->papier. 


1 


1 


1 










P3 


Visualiser 












FP74 


Visualiser des unites d'information ou des graphiques depuis 
I'interface de gestion de la base. 


1 


1 


1 








FP83 


Disposer d'un navigateur. 


1 


2 


3 


3 


3,81 


FP84 Prevoir un poste de controle des versions papier ou electroni- 
ques produites. 


1 


1 


1 


1 


1,27 


P4. Transmettre 






... 














































































TOTAUX 


36 


53 


68 


85 


108 



En repentant ces chiffres sur une courbe, on obtient finalement une representation 
dont un exemple est fourni par la figure 1-9. Les differences entre solutions apparais- 
sent alors de maniere visible et synthetique. Comparer les solutions en etudiant les rai- 
sons des differences de cout point par point devient, des lors, d'une grande simplicite. 



Figure 1-9 
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Etape 1 - La preparation du projet 

Chapitre 1 

On retiendra pour conclure qu'une telle representation parle tant aux techniciens qu'aux 
futurs utilisateurs ou decideurs. Elle est un outil de dialogue particulierement adapte. 



En resume... 



La methode que nous avons presentee permet tout a la fois de structurer la demarche 
projet et de representer de maniere parlante les fonctions du futur systeme, tout en 
fournissant des indices utiles quant aux couts respectifs des developpements, au 
nombre de fonctions « natives », et aux expertises necessaires au developpement. 

Le decoupage fonctionnel donne une premiere idee de l'architecture des composants 
logiciels a mettre en place tandis que la mise en evidence des services renseigne des le 
depart sur les flux de donnees internes et externes au systeme. 

Cette methode permet done de placer un certain nombre de bases qui sont autant de 
fondations du futur systeme. 

Appliquee prealablement a un choix definitif de solution, elle a l'avantage de reper- 
torier tres precisement les reelles fonctions du futur systeme, sans se limiter aux 
seules fonctions vues des utilisateurs. Les fonctions couteuses sont rapidement iden- 
tifiees. Les courbes permettent done aux decideurs de faire des choix de mise en 
oeuvre. Les chefs de projet ont un outil qui leur facilite les explications relatives a tel 
ou tel cout de developpement. 

Au terme de Implication de cette methode, vous apercevez les premieres relations 
liant les donnees aux fonctions du systeme, e'est-a-dire les grandes masses pour les- 
quelles des modeles de donnees devront etre developpes, cela avant meme de vous 
etre engage dans une quelconque etude detaillee. 



2 

Etape 2 - Realiser 
le modele conceptuel 



Toute personne ayant etudie plusieurs langues sait qu'un meme fait peut etre exprime 
de maniere assez differente d'une langue a l'autre. Chacune apporte sa propre pers- 
pective, ce qui enrichit l'analyse du fait etudie mais pose en meme temps des pro- 
blemes de traduction, puisqu'il y a rarement correspondance exacte entre les diffe- 
rentes perspectives. II en est de meme pour les langages formels comme UML ou 
XML. 



VOCABULAIRE Langage formel 

Langage qui utilise un ensemble de termes et de regies syntaxiques pour communiquer sans aucune 
ambigui'te (par opposition a langage naturel). Arrete du 30 decembre 1 983 - 7.0. du 1 9 fevrier 1 984. 



Entre UML et XML, la difference principale reside dans la maniere dont la notion 
de relation est envisagee. Les relations semblent une notion basique, qui devrait aller 
de soi. C'est pourtant un sujet qui demande a etre analyse avec attention. En particu- 
lier, UML et XML ont une maniere differente d'aborder les relations et il est essen- 
tiel d'en comprendre les differences si Ton veut etudier la correspondance entre ces 
deux langages. 



Etapes de la demarche de modelisation 

Premiere partie 

Nous etudierons en premier lieu la difference entre les modeles hierarchiques propres 
a XML et les modeles d'association propres a UML. Nous verrons ensuite comment 
XML et UML organisent les differents modeles qu'ils proposent en fonction de leur 
niveau d'abstraction. Enfin, nous nous interesserons au role de chacun de ces 
modeles dans les differentes etapes de conception de systeme de traitement de 
l'information. 



Difference entre modele hierarchique et modele 
d'association 

XML exprime l'information sous forme de relations hierarchiques constituees 
d'objets emboites les uns dans les autres a la maniere des poupees russes. De son cote, 
UML divise 1' analyse de l'information en deux categories ; d'un cote les objets et 
d'un autre cote les relations qui les unissent. Pour UML, les relations entre les objets 
ne sont pas systematiquement hierarchiques. Ce qui importe, pour UML, est la 
maniere dont les objets sont impliques dans les relations ; on dit aussi la maniere 
dont ils participent aux relations. Pour decrire cette participation, UML utilise la 
notion de role. Dans l'exemple que nous prenons ci-apres, Jean a cinq roles : acteur, 
membre d'une troupe, choriste, chefde choeur et peintre. Ces roles vont de pair avec ceux 
des autres objets auxquels Jean est associe : troupe, film joue, choeur, chozur dirige et 
tableau peint. 

Dans la figure 2-1, notre exemple est presente sous une forme uniquement hierar- 
chique. Lemboitement hierarchique ne fait apparaitre qu'une partie des roles evo- 
ques precedemment. Dans la figure 2-2, les relations sont au contraire plus explicites. 
Dans cette seconde representation, les relations sont sur le meme plan que les objets : 
c'est une caracteristique du modele UML. Le mot precisement utilise dans UML 
pour parler de ces relations est association. 

Exemple de representation en XML n'utilisant que les mecanismes d'emboitement 
d'elements pour simuler une stricte hierarchie 

<artiste nom="Jean"> 

<fi~lm_joue nom="Le grand bleu" /> 

<troupe nom="Troupe du theatre de Lyon"/> 

<Choeur nom="Choeur de 1 'opera de Vienne" /> 

<Choeur_di rige nom="Choeur de 1 'opera de Lyon" /> 

<Tableau nom="Champs de ble" /> 
</artiste> 
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Figure 2-1 
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Figure 2-2 Modele centre sur les associations 
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Les emboitements XML ont cet avantage (qui est en meme temps une limitation) de 
proposer de facto au moins deux relations (la relation parent-enfant et la relation de 
fratrie) qui suffisent a definir un sens de lecture aux donnees et conferent a rinforma- 
tion une organisation aux contours bien delimites. La relation parent-enfant de 
XML se traduit tres concretement par les emboitements bien connus des balises. 
Dans l'exemple precedent, le modele hierarchique se lit en partant de l'artiste Dean 
puis, suivant les balises, en decouvrant les films joues, troupes de theatre, chceurs 
d'opera etc. Dans le modele objet/association, il n'y a pas veritablement de sens de 
lecture. Cette derniere peut aussi bien commencer par Jean ou par Le grand bleu. 
Cette absence de sens de lecture vient du fait que les associations sont mises sur le 
meme plan que les objets. Lobjectif premier est de mettre en evidence la raison d'etre 
des associations qui unissent les objets, via les roles. lis donnent tres clairement, pour 
chacun des objets participants de l'association, la raison pour laquelle ils sont 
associes : chef de chceur pour Dean et choeur di rige pour Choeur de 1 'opera de Lyon. 

On percoit des maintenant les roles complementaires de UML et de XML : UML 
met en evidence ce qui est fondamental dans un modele de donnees - a savoir les 
associations qui unissent les donnees entre elles et leur raison d'etre - tandis que 
XML fournit aux programmes un sens de lecture structure de ces donnees qui per- 
mettra de les exploiter facilement. 

Dans la suite de cet ouvrage, nous utiliserons la notation UML pour representer les 
modeles de donnees sous Tangle des relations et XML pour montrer une implemen- 
tation concrete de ces relations. 



Modele d'objet UML et document XML 



Dans notre modele exemple precedent, nous avons utilise des mots correspondant 
aux objets et personnes du monde reel : Dean, Choeur del 'opera de Lyon, film joue, 
chceur di rige, etc. Le modele correspondant s'appelle modele d'objets dans UML et 
tout simplement document dans XML. Letape suivante consiste a identifier les carac- 
teristiques communes a tous les objets etudies pour les ranger dans des classes. Les 
modeles representant les caracteristiques communes aux objets s'appellent modeles 
de classes en UML et schemas XML en XML. 

Dans les paragraphes suivants, nous allons presenter le modele d'objets UML et le 
modele des documents XML. Les modeles de classes feront l'objet de la section sui- 
vante. 
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Modele d'objets UML 

Le modele d'objets UML est un graphe representant des objets individuels et les 
associations qui les unissent. II est souvent utile de produire un modele d'objets a 
titre d'exemple pour etudier des cas concrets avant l'etude de leurs caracteristiques 
communes faite dans le modele de classes. 

Une fois que le modele de classes est disponible, on peut revenir sur le modele 
d'objets pour y indiquer la classe dont chaque objet est une instance. Dans la 
figure 2-3, la notation utilisee fait apparaitre pour chaque objet son nom complete du 
nom de sa classe (les deux noms sont separes par le caractere deux-points). On peut 
ainsi lire que Jean est une instance de la classe Arti ste. 



VOCABULAIRE Faut-il dire instance ou occurrence ? 

La traduction francaise correcte du mot anglais instance est occurrence, et I'expression « modele 
d'occurrences » est celle utilisee par les editeurs dans les logiciels. Cependant, dans les communaut.es 
UML et SGML, le terme d'instance est couramment usite. C'est pourquoi nous I'avons conserve ici. 
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Figure 2-3 Modele d'objets UML avec reference aux classes des objets 



Modele de base des documents XML : Infoset 

De la meme maniere que Ton peut faire un modele d'objets UML independamment 
de tout modele de classes, on peut bien evidemment faire un document XML inde- 
pendamment de tout schema ou de toute DTD ; cela est d'ailleurs une caracteris- 
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tique fondamentale de XML, comme nous l'avons rappele dans l'introduction. C'est 
le modele Infoset qui indique comment tout document XML doit etre constitue, 
independamment de tous DTD et schema XML. 



Remarque La recommandation Infoset 

Infoset est une recommandation du W3C du 24 octobre 2001 disponible a I'adresse suivante : 
http://www.w3.org/TR/2001/REC-xml-infoset-2001 1 024/ 



D'apres la recommandation XML Infoset, un document XML est constitue de onze 
unites ({'information. Chacune d'entre elles est caracterisee par un ensemble de pro- 
prietes et est definie independamment de la syntaxe XML proprement dite (balise, 
balise de debut, balise de fin...). En effet, il est admis aujourd'hui que la representa- 
tion physique la plus repandue des documents XML - faite des signes < et > et des 
balises de debut et fin - n'en est qu'une des formes possibles. Quand un document 
XML est charge en memoire ou est stocke dans une base de donnees, sa forme differe. 

Ces unites d'information peuvent etre decrites de plusieurs manieres : 

• sous la forme de descriptions textuelles comme le fait la recommandation ; 

• sous la forme de schema RDF comme le propose la recommandation dans ses 
annexes ; 

• Enfin, sous la forme d'un modele UML comme nous l'avons fait a la figure 2-4. 



Technique xml : RDF 

RDF - pour Resource Description Framework- est une specification du W3C pour decrire les metadon- 
nees visant a offrir un langage de description de ressources Web comprehensible par les ordinateurs et 
les humains. Ce projet porte aussi le nom de « Web semantique ». Bien qu'un ensemble de metadonnees 
RDF s'ecrive sous la forme d'un document XML, RDF n'utilise ni les DTD ni les schemas XML pour en spe- 
cifier le modele, mais une technique qui lui est propre. La specification RDF est disponible sur le site du 
W3C a I'adresse suivante : http://www.w3.org/RDF. 



Nous fournissons egalement au tableau 2-1 un resume en texte naturel des defini- 
tions de ces onze objets, dont la presence dans les documents XML est autorisee par 
Infoset. Par ailleurs, nous en donnons une description plus precise en annexe de cet 
ouvrage. 

Infoset fournit ainsi le modele de tous les documents XML. D'un point de vue hie- 
rarchique, les unites d'information les plus significatives qui s'en degagent sont le 
document, les elements et les attributs. 
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Figure 2-4 Modele conceptuel d'un document XML selon la recommandation Infoset 
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Tableau 2-1 Description resumee des unites d'information d'lnfoset 
Proprietes 




L'unite d'information document est celle par laquelle commence le document XML. Souvent, 
elle est appelee prologue. 

Exemple : ci-apres trois lignes composees de deux instructions de traitement et d'une declara- 
tion de type de document qui sont les proprietes d'une unite d'information de type document. 
<?xmf version='1.0' ?> 

<?xmf : stylesheet type="text/xsl " href="sb.xsV'?> 
<!DOCTYPE SB SYSTEM "sb.dtd" []> 
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Tableau 2-1 Description resumee des unites d'information d'lnfoset (suite) 



Unite Proprietes 
d'information 


Element 


Les unites d'information de type element correspondent aux balises contenues dans un 
document XML. En particulier, I'element racine est une unite d'information de type element 
qui fait I'objet d'une propriete de l'unite d'information de type document. 

Exemple : <body> 


Attribut 


Ces unites d'information correspondent aux attributs portes par les elements. Elles sont utili- 
sees pour tous les attributs, y compris ceux definis avec une valeur par defaut dans la DTD, 
ainsi que I'attribut special de declaration d'espace de noms. 

Exemple : <pl ansect sectname="ef f "> 


Instruction II s'agit des instructions de traitement presentes dans le document XML. 
detraitement Exemple : <?xml version=' 1.0' ?> 


Reference d'entite 
non resolue 


L'unite d'information de type reference d'entite non resolue est un marqueur par lequel le pro- 
cesses XML indique qu'il n'a pas expanse I'entite. 

La definition de I'entite ainsi que son utilisation forment une seule unite d'information, par 
exemple : 

dans la DTD : 

< (ENTITY fig422 SYSTEM "c:/user/graphiques/image . tif "> 

et dans le document XML : 
<figure f"Me="fig422"/> 


Caractere 


II existe une unite d'information de ce type par caractere de donnee du document, meme ceux 
qui apparaissent sous la forme d'une codification, tels les caracteres accentues. 

Exemple : 

<p>bla bla bla</p> 

<p>m&eci r ; me</p> 

Dans la deuxieme ligne, I'appel d'entite &eci r ; represente le caractere e et est done consi- 
dere comme etant un appel d'unite d'information de type caractere. 


Commentaire 


II existe une unite d'information de ce type par commentaire present dans le document, sauf 
pour les commentaires deja inclus dans la DTD du document. 

Exemple :<!-- ceci est un commentaire --> 


Declaration 
de document 


Cette unite d'information existe quand le document XML a une declaration de type de docu- 
ment. Les eventuelles declarations d'entites et notations definies dans la declaration de type 
de document sont des proprietes de l'unite d'information de type document et non du docu- 
ment dans lequel la declaration est faite. 

Exemple : 

<!D0CTYPE SB SYSTEM "sb.dtd" [ 

<! NOTATION cgm PUBLIC "-//USA-DOD//NOTATION Computer Graphics 

Metafile//EN"> 

]> 
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Tableau 2-1 Description resumee des unites d'information d'lnfoset (suite) 



Unite Proprietes 
d'information 


Entite non 
analysee 


Une unite d'information de type entite non analysee existe pour chaque entite generale decla- 
ree dans la DTD. 

Exemple : 
<p>&sprsede2 ; </p> 

L'entite generale sprsede2 est definie dans la DTD, par exemple de la maniere suivante : 
<!ENTITY sprsede2 "Originator Supplies Superseded Publication 
Number Here"> 


Notation 


Une unite d'information de type notation existe pour chaque notation definie dans la DTD. 

Exemple : 

<! NOTATION cgm PUBLIC "-//USA-DOD//NOTATION Computer Graphics 

Metafile//EN"> 


Espace de noms 


Chaque element du document a comme propriete une unite d'information de ce type pour 
chaque espace de nom en vigueur au niveau de I'element. 

Exemple : 

<xsd: element xmlns :xsd="http://www.w3 .org/2001/XMLSchema"> 



Notion de classe 



A partir d'objets du monde reel, comme ceux de notre exemple precedent -Jean, Le 
Grand Bleu -, il faut pouvoir exprimer des notions plus generiques relies que : 

• Fi 1 m au lieu de Le Grand Bleu, 

• Arti ste au lieu de Dean, 

• Tableau au lieu de Champs de ble. 

Par ce processus d'abstraction, on definit alors des groupes d'objets ayant tous les 
memes caracteristiques : cela s'appelle une classe. Les objets d'une classe ont : 

• le meme jeu de caracteristiques communes : les proprietes ; 

• les memes associations aux autres objets : celles definies pour la classe. 

UML permet de definir une classe au travers de ses proprietes et de ses associations 
avec d'autres classes. 

Via les DTD ou XML Schema, XML definit des classes au travers de proprietes (les 
attributs des elements) et des relations d'emboitement qui lient les elements entre 
eux (relations parent-enfant et relations de fratrie). 

XML Schema a apporte une nouveaute importante : la definition d'une classe (un 
type) est dissociee de l'attribution d'un nom d'element. Ainsi, comme avec les DTD, 
si differents noms d'elements peuvent representer une meme classe, on peut egale- 
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ment avoir un meme nom d'element representant differentes classes en fonction de 
l'endroit ou il est utilise dans le document. Ce mecanisme est similaire a celui que 
jouent les noms de role dans les associations des modeles UML, a ceci pres que les 
elements XML definissent des relations d'emboitement alors que les associations 
UML ne sont pas systematiquement hierarchiques. 



Modeles et metamodeles 

Dans cet ouvrage, nous nous concentrons sur les modeles permettant de decrire les 
caracteristiques et structures communes que doivent respecter les donnees et docu- 
ments. C'est d'une part le modele de classe UML et d'autre part les differents types 
de schemas XML que sont les DTD, XML Schema, RelaxNG, etc... Dans cette sec- 
tion cependant, nous allons faire un apercu rapide des differents niveaux d'abstrac- 
tion qui permettent de decrire des modeles a partir d'autres modeles. On appelle ces 
modeles de modeles des metamodeles. On obtient alors un emboitement de modeles 
correspondant chacun a un niveau d'abstraction different 



VOCABULAIRE meta 

Le terme de meta est utilise dans metamodele et metalangage. Dans les deux cas, sa signification est la 
meme. Un metamodele est un modele qui sert a decrire d'autres modeles et un metalangage est un Ian- 
gage qui sert a decrire d'autres langages. 



Ainsi passe-t-on du modele d'objet decrivant Jean-Pierre en tant qu'Artiste au 
modele de classe decrivant les caracteristiques d'un artiste en general, puis au modele 
decrivant les concepts dont on se sert dans un modele de classe (classe, association, . . .). 
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Figure 2-5 Modeles et metamodeles 
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Le principe d'abstraction de modele a metamodele s'applique a XML et UML aussi 
bien qua d'autres langages de modelisation. II existe cependant une difference 
d'objectif entre XML et l'ensemble des techniques de modelisation associees a 
UML. Ce dernier fait partie d'une famille de metamodeles geree par l'OMG : 
Object Management Group. Pour gerer cette famille, il est necessaire d'avoir un 
autre modele permettant de decrire tous les metamodeles. C'est le role du MOF 
(Meta Object Facility) que Ton considere aussi comme un meta-metamodele. Le 
MOF apparait en fin de la chaine d'abstraction dans la figure 2-5. 

XML n'est pas un langage dedie a la modelisation et, de maniere operationnelle, n'a 
pas pour vocation de sensibiliser les concepteurs a la distinction entre metamodele et 
meta-metamodele. Aussi n'y retrouve-t-on pas la distinction effectuee dans UML 
entre classe et metaclasse. En revanche, XML fait la distinction entre un document 
et son modele de donnees appele plus generalement schema structurel. II existe 
d'ailleurs plusieurs types de schemas structurels pour XML et les plus repandus sont 
les DTD, XML Schema, RelaxNG et Schematron. Bien que la forme finale d'un 
document XML soit toujours la meme, les regies qui en specifient les structures peu- 
vent etre edictees de differentes manieres. Les unes vont s'attacher a definir des 
modeles de contenu (c'est l'approche DTD et RelaxNG), d'autres des types (c'est 
l'approche XML Schema), d'autres enfin vont s'attacher a definir des regies relatives 
a la valeur meme des donnees (c'est l'approche Schematron). Ainsi, sans etre com- 
pletement opposables (on peut parfaitement definir des structures avec Schematron 
par exemple), toutes les techniques de modelisation officielles ont leur singularite. 

XML dispose en outre d'un modele pour les documents bien formes - Infoset - qui 
s'applique a tout type de document XML. Ainsi, lorsque les schemas XML sont eux- 
memes exprimes en XML, ce qui est le cas d'XML Schema et de RelaxNG, on peut 
controler ou acceder a ces schemas a l'aide du modele Infoset. 

On peut illustrer notre propos par la figure 2-6 : 
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Figure 2-6 Modele de forme et schema 
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Modeles de donnees conccptucls, logiques et physiques 

Les premiers modeles de donnees a realiser dans 1' etude d'une application sont ceux 
qui decrivent les concepts mis en jeu dans le domaine etudie, independamment de 
toute implementation ou contrainte technique relative en particulier a la question du 
stockage des donnees. Ces modeles doivent aussi etre independants des langages uti- 
lises pour traduire concretement la structure de 1'information : en particulier de 
XML Schema, RelaxNG et Schematron. Pour ces raisons importantes, ces modeles 
sont dits conceptuels. 

Les modeles conceptuels mettent en ceuvre des concepts, definissent des vocabu- 
laires, donnent des limites et des caracteristiques aux objets et frxent les relations 
qu'ont les objets entre eux. lis doivent pouvoir etre exprimes simplement. Leur 
audience est a priori plus large que celle des experts informatiques puisqu'ils doivent 
aussi etre lus par des experts metier. Le diagramme de classes/associations d'UML 
est particulierement bien adapte pour representer des modeles conceptuels. La nota- 
tion graphique offerte par le diagramme de classes donne une vue synthetique des 
concepts et de leurs relations. Cette forme de representation est connue par une large 
communaute de concepteurs et d'analystes metier, ce qui permet une meilleure com- 
munication entre les equipes projets. 

Les modeles logiques ont pour objet la prise en compte de 1' architecture informa- 
tique dans laquelle s'integreront les donnees. C'est a ce niveau que sont definis les 
principes de structuration des donnees. Leur articulation en ilot de donnees se base 
sur les principes d'urbanisation du systeme et du decoupage de ce dernier en services 
comme cela a ete vu au chapitre 1. Pour les modeles logiques, on utilise tantot le for- 
malisme UML, tantot le formalisme XML, selon 1' expertise des acteurs du projet. 
C'est pour ce type de modele que Ton retrouve le plus souvent les debats sur la cor- 
respondance UML/XML. Ces derniers feront 1' objet du chapitre suivant. 

Enfin, les modeles physiques prennent en compte les syntaxes concretes qui seront 
utilisees pour capturer les donnees : des fichiers plats, une base de donnees relation- 
nelle ou XML, la validation par XML Schema ou RelaxNG, etc. 
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L'usage des differents types de modeles, conceptuels, logiques ou physiques s'inscrit 
le plus souvent dans une demarche de projet. De facon tres classique, on distingue les 
etapes d'analyse, de conception et de developpement. De maniere tout aussi clas- 
sique, on associe les modeles conceptuels a la phase d'analyse, les modeles logiques a 
la phase de conception et les modeles physiques a la phase de developpement (voir 
figure 2-7). 

Cependant, deux risques d'ecueils majeurs doivent etre evites lorsque Ton aborde les 
modeles de donnees sous Tangle de la demarche de projet : 

• Confondre le passage des modeles conceptuels aux modeles physiques avec le pas- 
sage d'une description simple - le modele conceptuel - a une description com- 
plete et detaillee - le modele physique. 

• Suivre a la lettre dans chaque projet la distinction entre modeles conceptuels, 
logiques et physiques. 

Lorsque le cas etudie est simple, il n'est pas utile de faire la distinction entre les trois 
types de modeles. Par exemple, si le cas etudie concerne un artiste et les tableaux qu'il 
a peints en vue d'un affichage a l'ecran, un simple fichier XML doit suffire pour 
representer les concepts, le deploiement et le stockage. Si, au contraire, on cherche a 
concevoir l'ensemble des portefeuilles de titres proposes par une banque en prenant 
en compte les differents canaux de distribution, il sera indispensable de distinguer les 
differents types de modeles lors de l'etude. 

Enfin, la distinction entre modeles conceptuels, logiques et physiques ne reside pas 
dans le niveau de detail de chacun. On peut determiner des transformations et des 
correspondances entre les differents modeles, mais il ne s'agit pas de « niveau de 
zoom » permettant de progresser du general au particulier. 

On retiendra que les modeles de conception, parce qu'ils ont pour objectif principal 
d'identifier les associations entres les concepts, feront plus largement usage d'UML. 
Pour la structuration des donnees et leur materialisation physique, XML est le can- 
didat naturel parce qu'il peut jouer le role de format d'implementation et parce qu'il 
propose intrinsequement des principes de structuration des donnees. 



Le cas PiloteWeb 



Presentation du cas 

LAAF - Association des aeroclubs de France - a pour objet de promouvoir les rela- 
tions entre pilotes amateurs afin de leur faire decouvrir les possibilites de voyage a 
titre prive en utilisant le reseau des aerodromes en France. Lassociation a decide de 
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mettre a disposition sur Internet une application permettant aux pilotes d'etablir des 
plans de vols a partir d'une description du reseau d'aerodromes et des facilites 
d'hebergement et de deplacement qui leur sont accordees. 

L'application est concue a la maniere des pilotes qui se reperent en fonction des sites 
geographiques. Chaque site est caracterise par un nom, une photo et une position 
definie en latitude et longitude. 

Outre leurs caracteristiques de sites, les aerodromes ont un code et une frequence 
radio. Pour chaque aerodrome, on dispose des conditions meteorologiques suivantes : 
la vitesse du vent, la temperature. 

Une liste de partenaires est associee a chaque aerodrome. Outre leurs caracteristiques 
de site, les partenaires ont une adresse et un numero de telephone. Les partenaires 
peuvent etre des aeroclubs, des loueurs de voitures ou des restaurants. Les restaurants 
precisent leurs horaires d'ouverture pour les repas de midi et du soir. 

Les pilotes sont identifies par leur adresse electronique et un mot de passe. lis ont 
aussi une position geographique qui permet de retrouver les pilotes presents sur le 
meme aerodrome. 

L'application PiloteWeb permet aux pilotes enregistres d'etablir des plans de vols. Un 
plan comprend plusieurs etapes. A chaque etape, l'application presente 1' aerodrome 
le plus proche, ainsi que la liste des partenaires de l'aerodrome et la liste des pilotes 
presents sur la zone. 

Modele conceptuel de donnees de PiloteWeb 

La construction d'un modele conceptuel de donnees se deroule generalement en trois 
grandes phases : decouverte des principaux concepts, mise au jour des principales 
relations, recherche et formalisation des concepts et relations intermediaires. 

Decouverte des principaux concepts 

La premiere phase de construction d'un modele conceptuel de donnees consiste tout 
simplement a lister les principaux concepts tels qu'ils apparaissent a la premiere lec- 
ture du cas etudie. Pour PiloteWeb, on peut distinguer clairement les concepts de 
pilote, d'aerodrome, de site, de partenaire, d'aeroclub, de loueur de voitures et de res- 
taurant. Les concepts sont representes par des classes en UML. De meme, certaines 
caracteristiques des concepts identifies apparaissent a la simple lecture du cas. II en 
est ainsi du nom du pilote, de son adresse electronique et de son mot de passe ; un 
partenaire a une adresse et un numero de telephone. Ces caracteristiques sont repre- 
sentees par des attributs de classe en UML. 
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Dans cette premiere etape de decouverte, on s'attachera a donner une definition pre- 
cise a chaque classe. Par exemple, la classe site decrit un lieu geographique et non 
pas un site Internet. 
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Decouverte des principals relations 

Dans un deuxieme temps, il faut faire apparaitre les relations entre les classes. On 
distingue deux types de relations. Les relations de sous-typage et les relations asso- 
ciatives ou associations. Les relations de sous-typage permettent de capitaliser des 
caracteristiques communes a certains concepts. Dans le cas de PiloteWeb, la classe 
Partenai re repond a ce critere de capitalisation. Les restaurants, les aeroclubs et les 
loueurs sont tous des cas particuliers de partenaires. lis sont done sous-types de la 
classe Partenai re. 

Dans UML, les relations de sous-typage sont representees par une fleche allant du 
sous-type vers son sur-type. II est possible de combiner les differentes fleches de rela- 
tion de sous-types pour alleger le diagramme. 
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Les associations indiquent un rapport existant entre deux classes. Un role indique, 
pour chaque classe, sa place dans l'association. Dans le cas de PiloteWeb, les pilotes, 
les aerodromes et les partenaires ont une association avec un site indiquant leur loca- 
lisation. Un site joue done les roles de localisation pilote, localisation 
aerodrome ou encore localisation partenai re. 

De maniere optimale, chaque role devrait avoir un nom. Ainsi, au role 1 ocal i sati on 
pilote correspond le role pilote localise. Cependant, l'usage veut que, lorsque 
l'association n'est pas ambigue, le nom donne au role soit celui de la classe qu'il 
represente. Dans ce cas, le nom du role est omis dans le diagramme de classe. C'est 
ce qui a ete retenu dans l'exemple PiloteWeb pour les roles d'Aerodrome et de 
Partenai re dans les associations avec la classe Site. 
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La recherche des noms de role est souvent un exercice delicat. C'est pourtant un 
excellent moyen d'eviter les approximations dans la conception des modeles de don- 
nees. Supposons, dans notre exemple PiloteWeb, que nous n'ayons pas donne les 
noms de role pi 1 ote 1 ocal i se et 1 ocal i sati on pi 1 ote a l'association entre Pi 1 ote 
et Site. On ajoute maintenant une nouvelle association definissant les roles de 
pilote responsable et site gere. La simple lecture de la figure 2-11 montre que 
Ton ne sait plus tres bien ce que signifie l'association sans nom de role entre Pilote 
et Si te. On devine que la classe Pi 1 ote a une association avec la classe Si te, mais on 
ne sait plus pourquoi. 

Les noms de role sont done porteurs de sens. On park de semantique de l'associa- 
tion. Labsence de nom de role laisse une liberte d'appreciation de la signification de 
l'association. Cela peut conduire a des erreurs d'interpretation du modele conceptuel 
lors du passage en phase de realisation. 
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Pour de nombreuses associations du modele, nous avons utilise la symbolique UML 
du losange. Dans UML, le losange blanc indique une agregation. Lagregation est 
une association type tout/partie exprimant une subordination faible entre deux 
classes telle que l'indique la figure 2-12. Le role representant le tout est le role d'agre- 
gation. II designe la classe « subordonnante » dans l'association. Lautre role repre- 
sente les parties ; c'est le role de subordination. II indique la classe subordonnee dans 
l'association. 
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Si Ton retire une des parties d'un tout, ce dernier s'en trouve modifie. Par exemple, 
pour l'association entre Pilote et Site (voir figure 2-10), le role pilote localise 
indique que la classe Pi lote est l'agregat. Si Ton retire cette association, la definition 
de Pi 1 ote s'en trouve modifiee alors que celle de Si te reste inchangee. Pour savoir si 
un des roles d'une association est un agregat, il faut done se poser la question 
suivante : y a-t-il une classe dont la definition se trouve modifiee par l'ajout ou la 
suppression de l'association ? 

Linteret de reperer les agregations est de permettre une premiere identification du 
responsable de l'association. Nous verrons dans le chapitre sur les modeles logiques 
que cette information est utile pour les choix d 'implementation des associations dans 
les modeles physiques XML. 
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Outre 1' agregation simple, le modele de classe UML comprend un autre type d'agre- 
gation appele « composition ». Les compositions sont representees par des losanges 
noirs. Elles indiquent que les parties sont gerees hierarchiquement par rapport a 
l'agregat : toute suppression de l'agregat entraine la suppression de ses parties. Dans 
l'exemple de PiloteWeb, toute suppression d'un site entraine la suppression de sa 
photo. On dit de la composition quelle est une agregation forte. 



Figure 2-13 
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La specification d'une composition dans un modele conceptuel est une indication 
que l'association sera probablement geree par un emboitement parent/enfant dans 
l'implementation physique du modele en XML. 



Recherche et formalisation des concepts et relations intermediates 

Certains concepts et relations ne se deduisent pas de la simple lecture du cas a ana- 
lyser. II faut faire un effort d'analyse et des choix de modelisation, a savoir : 

1 Determiner si une donnee donne lieu a une classe ou a un attribut. 

2 Determiner si une donnee donne lieu a une classe ou a une association. 

Le cas des horaires de restaurant de PiloteWeb est un bon exercice. Reprenons 
l'enonce du cas : « Les restaurants precisent leurs horaires d'ouverture pour les repas 
de midi et du soir. » Une premiere proposition de modelisation pourrait etre repre- 
sentee par la figure 2-14. II apparait cependant que ce choix de modelisation 
melange la representation d'une classe - la classe Restaurant - et celle d'un type de 
donnees - Heure. Dans UML, un type de donnees (ou data type en anglais) ne peut 
pas avoir d'association. Le modele de la figure 2-14 est done invalide. 



Etape 2 - Realiser le modele conceptuel 

Chapitre 2 



VOCABULAIRE Type de donnees 

Un type de donnees definit les valeurs que peut prendre une donnee. Les type de donnees de base sont 
par exemple enti er, caractere. 

UML permet de definir des types de donnees structures sous forme d'arborescence d'attributs. Par exem- 
ple, le type adresse est compose de rue, ville et code postal. 
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Le modele corrige est fourni par la figure 2-15. Le choix de modelisation consiste a 
representor les horaires comme des attributs de restaurant, attributs dont le type de 
donnees est heure. 
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Cependant, le modele de la figure 2-15 n'est pas encore satisfaisant. En effet, un 
horaire, ce n'est pas seulement une heure mais une heure d'ouverture et une heure de 
fermeture. II nous faut done faire emerger la classe Horai re en tant que telle avec un 
attribut heure d'ouverture et un autre attribut heure de fermeture. La classe 
Horaire a ensuite deux associations avec Restaurant ou elle joue les roles 
horai re midi et horai re soi r tel que represente a la figure 2-16. 
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L'analyse du cas pourrait se satisfaire de cet etat du modele. Cependant, un doute 
subsiste encore : est-ce que Ho ran re est vraiment une classe ou seulement un type de 
donnees ? On ne peut pas donner de reponse absolue a cette question. C'est un choix 
de modelisation qui se pose dans les termes suivants : 

• Veut-on gerer des listes d'horaires independantes et reutilisables ? 

• Les horaires ont-il des associations avec d'autres concepts ? 

En cas de reponse affirmative a l'une ou l'autre de ces deux questions, il faudra consi- 
derer Horaire comme une classe. Dans le cas contraire, on considerera Horaire 
comme un simple type de donnees. C'est cette derniere solution que nous retien- 
drons pour Implication PiloteWeb dont la vocation premiere n'est pas de gerer des 
horaires. On obtient ainsi le modele conceptuel de donnees de PiloteWeb, presente a 
la figure 2-17 : 
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Figure 2-17 Modele de donnees conceptuel de PiloteWeb 
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Synthese 



La recherche des concepts et relations intermediates nous a permis de decouvrir 
quelques regies essentielles pour la modelisation de donnees : 

1 Un concept est represente par une classe. Une classe est caracterisee par ses attri- 
buts et les roles dans les associations auxquelles elle participe. 

2 Pour differencier une classe d'un type de donnees, il faut se poser les questions 
suivantes : 

- Veut-on gerer ces donnees sous forme d'objets independants et reutilisables ? 

- Les donnees representees devront-elles avoir des associations avec d'autres 
donnees ? 

Une reponse affirmative a l'une ou l'autre de ces deux questions indique que la 
donnee doit etre representee par une classe. Dans le cas contraire, on a vraisem- 
blablement affaire a un type de donnees. 

3 Nommer les roles des associations permet de preciser la raison d'etre de l'associa- 
tion, et c'est un gage de clarte et de precision du modele. 

4 Dans de nombreux cas, on peut distinguer les associations pour lesquelles une des 
classes joue le role de tout (agregat). La notion d'agregation d'UML permet de 
caracteriser de telles associations. La decouverte des agregations est une indica- 
tion importante lors de la transformation du modele conceptuel en modele XML. 

II faut bien observer qu'il y a toujours une part de subjectivite dans les choix de 
modelisation. II serait vain de penser que la simple application des regies que nous 
venons d'enoncer permet automatiquement de trouver le bon modele. Dans Pilote- 
Web, par exemple, nous avons choisi de representer les photos comme une classe. 
Cependant, si Ton applique la regie de distinction classe/type de donnees, elles 
devraient etre uniquement un attribut de site avec un type de donnees Photo : en 
effet, PiloteWeb n'est pas une gestion d'album de photos. Cependant, l'experience 
courante nous fait percevoir les photos comme des objets a part, et nous sommes 
naturellement enclins a les representer sous la forme d'une classe Photo. Le choix 
d'implementation se fera au niveau des modeles logiques. 
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En resume... 



Nous avons mis en avant la difference d'approche entre UML et XML : l'un repre- 
sente un modele de donnees base sur des relations associatives, l'autre sur la hierar- 
chie des relations entre les donnees. 

Les deux approches se completent mais peuvent poser un probleme de mise en cor- 
respondance si Ton pense pouvoir generer automatiquement un schema XML a 
partir d'un modele UML. Notre conseil est de combiner intelligemment les deux 
approches, en privilegiant l'emploi du modele de classe d'UML pour l'analyse con- 
ceptuelle des modeles de donnees et celui d'XML pour la conception des modeles 
physiques. 

Au travers du cas PiloteWeb, nous avons pu analyser la representation conceptuelle 
d'un modele de donnees et preciser la methode permettant de decouvrir les concepts 
de classes et relations. Dans le chapitre suivant, nous aborderons les specificites des 
modeles logiques a partir des resultats obtenus dans l'analyse des modeles conceptuels. 
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On passe d'un modele conceptuel a un modele logique quand on decide de la 
maniere dont on va diviser l'organisation des donnees en un modele ou plusieurs. 
Dans le cas de XML, on tient alors compte des elements de structuration propres a 
XML pour etablir : 

• le decoupage du modele conceptuel en modeles logiques ; 

• les frontieres entre chacun des modeles logiques ; 

• les espaces de noms utilises ; 

• la maniere dont seront mis en oeuvre les mecanismes de derivation, d'abstraction 
et d'unicite ; 

• la gestion des attributs ; 

• la gestion des associations. 

Pour des raisons pratiques, nous n'allons considerer dans ce chapitre que le seul lan- 
gage d'ecriture de schemas XML Schema du W3C. Toutefois, il y a d'autres lan- 
gages de modelisation de donnees XML, tels que les DTD, Relax NG, Schematron, 
et enfin la notation BNF. 
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Decoupage du modele conceptuel en modeles logiques 

Le modele conceptuel represente le plus souvent une vue globale, pour laquelle les 
considerations sur l'organisation des donnees en modules n'ont pas encore ete arre- 
tees. Le decoupage en modules de donnees revet une importance majeure tant sur le 
plan de 1'architecture d'un systeme d'information que sur celui de la technique de 
gestion des donnees. C'est l'etude de ce decoupage qui fait justement l'objet de la 
mise au point du modele logique. 



VOCABULAIRE Module de donnees 

Nous allons devoir utiliser dans ce chapitre le concept de module de donnees. C'est un concept important 

qui fait, a lui tout seul, l'objet des chapitres 9 et 10. 

Contentons-nous ici de retenir que toutes les donnees qui sont utilisees par une application ne peuvent 

pas etre regroupees pele-mele dans un meme tas. Elles doivent etre organisees, structures et comparti- 

mentees afin que les developpeurs et tous les intervenants de la programmation s'y retrouvent. 

En particulier, le compartimentage de cet ensemble de donnees en sous-ensembles logiques donne nais- 

sance a ce que nous appelons modules de donnees, a savoir des Tlots qui, pour des raisons logiques que 

nous expliquons dans ce chapitre, doivent se trouver reunis physiquement. 



Pour disposer d'un systeme d'information agile, ce dernier doit etre organise en diffe- 
rentes zones autonomes, reliees par des voies de communication, ainsi que nous 
l'avons expose au chapitre 1. Ce decoupage en zones autonomes est guide par des cri- 
teres metier lies, d'une part, aux fonctions attendues du systeme et a la maniere dont 
elles sont sollicitees par les processus de l'entreprise, et d'autre part, a l'identification 
des grands objets de gestion tels que les clients, les fournisseurs, les produits, etc. 

Une approche centralisatrice a longtemps fait miroiter l'idee d'un modele de donnees 
universel ou les differents points de vue pourraient etre reconcilies au sein d'une 
meme base de donnees. L'evolution incessante des systemes et des besoins des entre- 
prises a montre qu'il s'agissait d'un reve : le modele de donnees est-il bien le meme 
dans les cadres des processus de vente et du traitement des reclamations ? Ce qui 
peut apparaitre accessoire dans le premier cas sera peut-etre essentiel dans l'autre. II 
faut done identifier parmi les donnees celles qui doivent faire l'objet de blocs indisso- 
ciables, d'autres qui doivent avoir leur propre cycle de vie et etre autonomes. 

Sur le plan technique, la modularisation des donnees permet d'identifier les points 
d'articulation et de liaison qu'il faudra mettre en place entre chacun des modules de 
donnees. En XML, ces points d'articulation se feront a partir d'elements specifiques 
(voir les chapitres 9 sur les elements purement structurels et 10 sur les modules 
d'information) et de choix dans les techniques de gestion des liens (voir chapitre 12 
sur les liens : IDREF, XLink, etc.). La conception du modele logique est done une 
etape importante dans le cadrage des choix d'architecture de donnees. 
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Le point d'equilibre dans la definition des modules se situe entre deux extremes : l'un 
serait l'eclatement maximal du modele conceptuel en une myriade de petits modeles 
XML et l'autre le regroupement monolithique de toutes les classes en un seul modele 
XML insecable. Atteindre a l'un ou l'autre modele ne serait que le reflet d'une mau- 
vaise analyse des fonctions et zones du systeme. Le fractionnement extreme corres- 
pond au cas ou chaque acteur du systeme aurait fait valoir son propre point de vue de 
maniere independante et ou chaque classe du modele conceptuel donnerait lieu a un 
module d'information autonome. Cela permet un fort taux de reutilisation des 
modules mais au prix d'une gestion trop complexe des liens inter-modules. Le 
regroupement extreme correspond au cas ou un acteur dominant aurait reussi a 
imposer son point de vue aux autres. II en resulte une organisation monolithique du 
systeme, repondant aux seuls besoins de l'acteur dominant. 

A travers le cas simplifie de PiloteWeb, nous allons decrire les principaux criteres uti- 
lises pour segmenter des modeles conceptuels en modeles logiques : 

• identifier les classes majeures et leur perimetre ; 

• regrouper les classes dans des modeles distincts ; 

• creer les dependances entre modeles ; 

• choisir les espaces de noms. 

Identifier les objets majeurs et leur perimetre 

Dans la phase d'analyse du modele conceptuel, nous avons deja identifie une liste des 
principaux concepts de PiloteWeb: pilote, site, aerodrome, restaurant, 
partenai res, "loueur. II nous faut maintenant les examiner un par un pour deter- 
miner leur contour a partir des questions suivantes : 

• Quelles associations font partie du domaine de definition de chaque classe ? 

• Quelles relations de generalisation/sous-typage font partie du domaine de defini- 
tion de chaque classe ? 

• Quelles classes principales doivent etre gerees en commun ? 

Analyse des associations 

Dans le cas de PiloteWeb, nous commencerons par l'analyse de la classe Si te. La 
premiere tache a realiser est de determiner son contour. A cet effet, une premiere 
indication est fournie par les caracteristiques d'association que nous avons definies 
dans le modele conceptuel, et, en particulier, les caracteristiques d'agregation et de 
composition. 

Comme nous 1' avons vu au chapitre 2, la composition implique une association forte 
entre deux classes. La classe Si te joue le role d'agregat fort dans l'association avec la 
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classe Photo. Cela veut dire que Photo est subordonnee a Si te. Ces deux classes et 
l'association devront done etre regroupees dans le meme modele logique. Pour toutes 
les autres associations auxquelles elle participe, la classe Si te joue uniquement des 
roles de subordonnee (en d'autres termes de partie). Ces associations et leurs partici- 
pants sont done exclus du modele logique de la classe site. 




Modele conceDtuel de donnees 



Partenaire 



+adresse:Adresse 
+telephone:Telephone 



~zy 



Restaurant 



+horaire midi:Horaire 
+horaire soir:Horaire 
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Aeroclub 



+adresse:Adresse 
+telephone:Telephone 



Loueur 



+adresse:Adresse 
+telephone:Telephone 
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site photographie 1 



photo 
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Figure 3-1 Contour de la classe Site 
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Le modele logique de la classe si te est decrit par un nouveau paquetage UML qu'on 
baptise sites, dans lequel on place une copie des classes Site et Photo du modele 
conceptuel (figure 3-1). 



VOCABULAIRE Paquetage 

Un paquetage UML est le regroupement d'objets du modele. Les objets regroupes par un paquetage sont 
les classes, les associations et les relations de generalisation/specification. 



Des relations peuvent etre etablies entre les classes du modele conceptuel et leur 
clone du modele logique afin de ne pas en perdre la trace. Pour cette raison, ces rela- 
tions sont denommees « relations de tracabilite ». Ce trace s'effectue en utilisant le 
mecanisme de « dependance » de UML 2.0. Nous l'avons represente a la figure 3-2 
au moyen de traits en pointilles reliant les classes du modele logique a leur source 
dans le modele conceptuel. 



VOCABULAIRE Dependance 

Une dependance est une relation signifiant qu'un element de modelisation requiert un autre element de 
modelisation pour completer sa specification ou son implementation. 



Les modeles logiques presentent le plus souvent des variations importantes avec les 
modeles conceptuels. C'est pourquoi leurs classes sont obtenues par duplication de 
celles des modeles conceptuels. Les relations de dependance permettent de garder la 
trace de la classe du modele conceptuel dont provient chaque classe du modele 
logique. II est fait de meme pour les associations. Par exemple, dans la figure 3-1, 
nous indiquons que l'association qui relie les classes site et photo du modele logique 
est une copie de celle qui unit leurs homologues dans le modele conceptuel. 



Remarque Regie de denomination des classes des modeles conceptuels et logiques de 
PiloteWeb 

Afin de distinguer les classes du modele conceptuel de celles du modele logique, nous avons adopte dans 
cet ouvrage la convention suivante : le nom des classes du modele conceptuel commence par une majus- 
cule tandis que celui des classes du modele logique commence par une minuscule. 



Dans le nouveau paquetage cree, la classe site est considered comme une classe 
entite, dont les occurrences seront gerees dans le module de donnees sites. Par con- 
vention, les classes entites du paquetage sont representees par un rectangle gris, 
comme le montre la figure 3-1. 
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La classe photo, en revanche, n'est pas consideree comme une classe entire du 
module sites. 



Remarque Classe entite et UML 

UML specifie une categorie particuliere de classe entite au moyen du stereotype « entite ». Cependant, 

cette etiquette apposee a une classe ne permet pas d'en determiner le contour sous forme d'un module 

de donnees. Ce n'est qu'une etiquette. 

La solution proposee dans cet ouvrage consiste a definir un contour a une classe entite a I'aide d'un 

paquetage. Ce paquetage determine les associations et classes, et seulement celles qui doivent etre 

gerees en commun avec la classe entite. 

UML ne propose pas en standard de moyen de designer la ou les classe(s) entite(s) d'un paquetage. La 

solution retenue est d'utiliser une relation de dependance entre paquetage et classe. 
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Figure 3-2 Contour de la classe Pilote 
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Pour la classe Pi 1 ote du modele conceptuel, on precede de la meme maniere que 
pour la classe Si te : on cree un nouveau paquetage UML pi 1 otes (figure 3-2) et on 
recherche les classes et associations qui doivent en faire partie a la lecture du modele 
conceptuel. La classe Pi 1 ote a une association avec Si te (elle sert a indiquer la posi- 
tion geographique du pilote). La classe Pi 1 ote y joue le role d'agregat, c'est pourquoi 
l'association doit faire partie du paquetage pi Totes. 

Linclusion de la classe site dans le paquetage pi Totes montre qu'il peut exister des 
relations de dependance entre les paquetages. Sur la figure 3-3, on voit de quelle 
maniere nous pouvons le representer graphiquement. Lidentification de ces depen- 
dances est un point d'analyse important. Celles que nous mettons ici en evidence se 
traduiront plus tard par des liens entre les modules de donnees de l'application. On les 
verra done reapparaitre lorsqu'on va construire les modeles physiques de l'application. 

Figure 3-3 l 

Dependance entre paquetages sit „ 
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Analyse des relations de generalisation/specialisation 

Lanalyse de la classe Partenai re du modele conceptuel pose la question du traite- 
ment des relations de generalisation/specialisation, aussi denommees relations de 
sur-type/sous-type. 



VOCABULAIRE Relation de generalisation/specialisation 

Une relation de generalisation est le resultat d'une operation oil les caracteristiques communes a plu- 
sieurs classes sont regroupees dans une classe plus generale, aussi appelee sur-type. Reciproquement, 
une relation de specialisation est le resultat d'une operation d'enrichissement oil des caracteristiques dis- 
tinctives sont ajoutees aux classes specialises, aussi appelees sous-types, en sus des caracteristiques de 
la classe generale. Les relations de generalisation et de specialisation vont de pair et sont la reciproque 
I'une de I'autre. 

De maniere plus concise, les experts en modelisation utilisent souvent le terme de « generalisation » 
pour designer a la fois la « relation de generalisation » et la « relation de specialisation ». 



Dans cet ouvrage, nous utilisons les seuls termes de sur-type pour la classe la plus 
generale, de sous-type pour la classe specialisee et de generalisation pour la relation 
qui les unit. La figure 3-4 fixe visuellement cette terminologie. 



Etapes de la demarche de modelisation 

Premiere partie 



Figure 3-4 
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Nous avons explique au chapitre 2 que la generalisation correspond a une operation 
de factorisation par laquelle on reunit sous une meme classe les caracteristiques com- 
munes a plusieurs autres classes. C'est une operation qui porte sur deux points : 

• La mise en commun des caracteristiques des classes (leurs attributs et roles) ; par 
exemple, les attributs Telephone et Adresse sont reunis dans la classe generale 
Partenai re (figure 3-1), car ils sont communs aux classes Restaurant, Aeroclub 
et Loueur. 

• La mise en commun des occurrences des classes. Ainsi, dans le modele conceptuel 
de PiloteWeb de la figure 3-1, les generalisations indiquent que les occurrences 
des classes Restaurant, Loueur et Aeroclub sont aussi indirectement des occur- 
rences de la classe Partenai re. 



VOCABULAIRE Occurrence de classe 

On appelle occurrence d'une classe sa transposition dans le monde reel. Par exemple, les occurrences des 

classes UML dont nous parlons seront des instances de « classes Java » ou des elements XML. 

Pour simplifier, et puisque nous sommes dans le monde de la donnee XML, on acceptera I'idee generale 

que les occurrences des classes que nous presentons seront les elements XML et leur contenu qui, tres 

concretement, formeront les documents XML de notre I'application. 

Pour designer I'operation de creation d'occurrences, on utilise aussi les termes d'« instanciation » ou 

d'instance a partir d'une classe. Les termes d'instances et d'occurrences sont done equivalents. 

« Instancier- En programmation orientee objet, creer a partir d'une classe une occurrence de cette 

classe, heritant par defaut des attributs de sa classe, et qui peut etre dot.ee d'attributs specifiques » 

(reference : le Grand Dictionnaire terminologique — Office de la langue francaise du Quebec — 

http : //www . granddi cti onnai re . com). 
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Dans le cadre de la creation des modeles logiques, il faut cependant decider dans quel 
module de donnees les occurrences seront gerees physiquement. Si les occurrences de 
restaurants sont gerees a la fois dans un module restaurants et dans un module 
partenaires, on ne saura pas, lors de la pose des liens, quel module cibler pour 
trouver les restaurants. En effet, pour qu'une occurrence soit adressable, elle doit etre 
localisee dans un et un seul module de donnees : il faut que le lien soit 
« biunivoque », c'est-a-dire sans ambiguite. Dans l'analyse des generalisations que 
nous conduisons a ce stade de i'elaboration du modele logique, notre objectif est clai- 
rement de determiner ou se trouveront les occurrences physiques des classes qui 
apparaissent dans les paquetages du modele logique. A cette fin, nous allons devoir 
prendre en compte les concepts d'abstraction. 



VOCABULAIRE Classe abstraite 

line classe abstraite ne peut pas avoir d'occurrence. Une classe est declaree abstraite soit parce que sa 
specification est incomplete, soit par pure decision de conception. 

Parexemple, dans une hierarchie de classes comprenant la classe personne et ses sous-types client 
et employe, il peut etre decide arbitrairement que la classe personne est abstraite. Cela signifie que 
la classe personne n'apparaTtra jamais directement dans le systeme reel mais toujours sous la forme 
des classes client et employe. En d'autres termes, le systeme reel ne gerera pas d'occurrence de 
personne mais uniquement des occurrences de cl i ent et empl oye. 



Definition Classe concrete 

Une classe concrete est une classe qui peut avoir des occurrences. 



On distingue trois methodes de prise en compte des relations de sur-type/sous-type : 

• Le sur-type est concret et les sous-types sont abstraits. 

• Le sur-type est abstrait et les sous-types sont concrets. 

• Le sur-type est concret et les sous-types sont concrets. 

II existe theoriquement un quatrieme cas, celui ou le sur-type et les sous-types sont 
abstraits. Dans ce cas, le modele ne peut pas etre implemente, car il ne peut exister 
aucune occurrence des classes concernees (en l'occurrence partenai re, restaurants, 
loueurs et aroclub). Ce quatrieme cas nest done pas retenu. 

l er cas. Le sur-type est une classe concrete et les sous-types sont des classes abstraites 

Dans ce premier cas, la classe Partenai re du modele conceptuel donne lieu, par 
duplication, a une classe concrete partenai re dans le modele logique. Les classes 
Restaurant, Loueur, Aeroclub du modele conceptuel donnent lieu, par duplication, 
aux classes abstraites restaurant, loueur, aeroclub dans le modele logique. 
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Les occurrences de la classe partenai re ont au choix les caracteristiques des classes 
abstraites restaurant, "loueur ou aeroclub; il n'existe pas, a proprement parler, 
d'occurrences de restaurants, loueurs ou aeroclubs. 

Plusieurs solutions d'implementation se presentent : un typage statique ou dyna- 
mique de la classe partenai re. 

Pour mettre en oeuvre le typage statique, on opere de la maniere suivante : 

• On ajoute un attribut typepartenai re a la classe partenai re du modele logique. 
Cet attribut se traduira egalement dans le XML par un attribut de meme nom 
(voir tableau 3-1). II a pour type une enumeration dont les valeurs sont 
restaurant, loueur, aeroclub. 

• On inclut dans la classe partenai re du modele logique l'ensemble des attributs et 
associations des classes restaurant, loueur et aeroclub. Dans le modele XML 
correspondant, on regroupe dans un meme element toutes les caracteristiques des 
restaurants, aeroclubs et loueurs. II reviendra done a 1' application de savoir appli- 
quer les bons traitements ou produire les bons sous-elements en fonction de la 
valeur de l'attribut typepartenai re. Cette solution est celle retenue le plus sou- 
vent dans les applications de XML au monde relationnel qui ne dispose pas de 
possibilite de typage dynamique. 

Ce cas de figure est illustre au tableau 3-1. 



Tableau 3-1 Generalisation : typage statique 



Modele logique UML 

Attribut de typage statique 




localisation partenaire 



0..1 



-o 



partenaire 



+type partenaire:typepartenaire 
+telephone:telephoneType 
+adresse:adresse 
+horaire midkhoraire 
+horaire soinhoraire 



<<Enumeration>> 

typepartenaire 



restaurant 
aerodrome 
aeroclub 
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Tableau 3-1 Generalisation : typage statique 

Representations XML possibles et explications 

Implementation sous forme d'un attribut discriminant 

<xs : element name="partenai re"> 
<xs : compl exType> 
<xs:sequence> 

<xs: element name=" localisation Partenai re" 

type="enti tyRef "/> 
<xs:element name="adresse" type="adresse"/> 
<xs: element name="telephone" 

type="tel ephone"/> 
<xs: element name="midi" type="horai re"/> 
<xs: element name="soir" type="horai re"/> 
</xs:sequence> 

<xs : attri bute name="typepartenai re" 
use="requi red"> 
<xs:simpleType> 

<xs: restriction base="xs:string"> 
<xs : enumeration value="restaurant"/> 
<xs : enumeration value="loueur"/> 
<xs : enumerati on val ue="aerocl ub"/> 
</xs : restri cti on> 
</xs:simpleType> 
</xs: attri bute> 
</xs : compl exType> 
</xs:element> 



Pour mettre en oeuvre le typage dynamique, on opere de la facon suivante : 

• La classe Partenaire du modele conceptuel donne lieu a une classe abstraite 
partenai reType et une classe concrete partenai re. 

• Les sous-types de la classe Partenai re dans le modele conceptuel- Restaurant, 
Loueur, Aeroclub - donnent lieu a des classes abstraites dans le modele logique : 
restaurantType, loueurType et aeroclubType. Ces classes sont des sous-types de 
la classe abstraite partenai reType. 

Dans le schema XML correspondant, la classe partenai re devient 1' element 
partenai re dont le type, abstrait, est partenai reType. Trois types sont definis qui 
sont restaurantType, loueurType et aeroclubType. lis peuvent se substituer au type 
abstrait car ils en sont des derives valides. Aussi, dans les documents XML con- 
formes a ce schema, il sera obligatoire d'utiliser 1'attribut xsi :type sur chaque ele- 
ment partenaire pour indiquer son type concret. 
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Tableau 3-2 Realisation d'un typage dynamique 

Modele logique UML 

Classe concrete avec un type abstrait 



partenaireType 

{Abstract} 



+Adresse:adresse 
+telephone:telephone 









A. 
























loueurType 

{Abstract} 




aeroclubType 

{Abstract} 




restaurantType 

{Abstract} 


tnom:nom 


+nom:nom 


+horaire midiihoraire 
+horaire soinhoraire 
+nom:nom 



Partenaire 



Representations XML 

Implementation sous forme de type dynamique 

<xs: compl exType name="partenai reType" abstract="true"> 
<xs:sequence> 

<xs: element name=" localisation Pa rtenai re" 

type="enti tyRef "/> 
<xs:element name="adresse" type="adresse"/> 
<xs: element name="telephone" type="telephone"/> 
</xs:sequence> 
</xs : compl exType> 

<xs : compl exType name=" restau rantType"> 
<xs : compl exContent> 

<xs :extension base="partenai reType"> 
<xs:sequence> 

<xs:element name="midi" type="horai re"/> 
<xs: element name="soir" type="horai re"/> 
</xs :sequence> 
</xs:extension> 
</xs : compl exContent> 
</xs : compl exType> 

<xs: element name="partenai re" type="partenai reType"> 
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Tableau 3-2 Realisation d'un typage dynamique 



Exemple de document instance 

<partenaire xsi :type="restaurantType"> 

<pw:localisationRestaurant xl :type="simple" 

xl :href="http://www.pilotweb. com#"/> 

<pw: adresse>Stri ng</pw: adresse> 

<telephone>0230548967</telephone> 

<mi di >St ri ng</mi di > 

<soi r>String</soi r> 
</partena"i re> 



2 e cas. Le sur-type est une classe abstraite et les sous-types sont des classes concretes 

La classe Partenaire du modele conceptuel donne lieu a une classe abstraite 
partenai reType dans le modele logique. Elle est simplement utilisee pour factoriser 
des caracteristiques propres aux partenaires. II n'y a pas d'occurrence de partenaire 
mais seulement des occurrences de restaurant, d'aeroclub et de loueur. Chaque sous- 
type de la classe Partenai re dans le modele conceptuel donne done lieu a une classe 
concrete dans le modele logique : restaurant, loueur, aeroclub. Ces classes heri- 
tent des caracteristiques de la classe abstraite partenai reType. 

La correspondance avec le schema XML repond aux regies suivantes : 

• La classe abstraite partenai reType donne lieu a un type complexe du meme nom. 

• Les classes concretes restaurant, loueur, aeroclub donnent chacune lieu a un 
element dont le type est une extension de partenai reType. 

Ce cas de figure est illustre au tableau 3-3. 

Tableau 3-3 Le sur-type est une classe abstraite 

Modele logique UML 

Classe concrete avec un type abstrait 



partenaireType 

{Abstract} 



Adresse:a<te5se 
-telephone:te[ephone 



site 


l<x:r*]i!;rtlic>n rcj^trfljiiirl 






1 





restaurant 

horare midi: horaire 
ihoraire soinhorafre 
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Tableau 3-3 Le sur-type est une classe abstraite 

Representations XML possibles et explications 

La classe concrete donne lieu a un element global definissant un type local base sur un type abstrait 

<xs:complexType name="partenai reType" abstract="true"> 
<xs:sequence> 

<xs:element name="adresse" type="adresse"/> 
<xs: element name="telephone" type="telephone"/> 
</xs:sequence> 
</xs : compl exType> 

<xs:element name="restaurant"> 
<xs : compl exType> 
<xs : compl exContent> 

<xs : extensi on base="partenai reType"> 
<xs:sequence> 
<xs: element 

ref="localisationRestaurant"/> 
<xs: element name="midi" type="horai re"/> 
<xs: element name="soir" type="horai re"/> 
</xs: sequence> 
</xs: extensi on> 
</xs : compl exContent> 
</xs : compl exType> 
</xs:element> 



3 e cas. Le sur-type est une classe concrete et les sous-types sont des classes concretes 

Ce cas correspond a la transformation des generalisations du modele conceptuel en 
relations associatives dans le modele logique selon les regies suivantes : 

• Chaque classe participant a la generalisation dans le modele conceptuel donne lieu a 
une classe concrete dans le modele logique. Dans PiloteWeb, les classes Partenai re, 
Restaurant, Loueur, Aerocl ub du modele conceptuel donnent lieu aux classes con- 
cretes partenai re, restaurant, loueur, aerocl ub du modele logique. 

• Chaque generalisation du modele conceptuel est transformee dans le modele logi- 
que en une association d'agregation. Dans le cas de PiloteWeb (figure 3-5), cela 
amene la classe partenai re a avoir trois nouvelles associations : une pour cha- 
cune des classes restaurant, loueur et aerocl ub. 

• Pour chacune de ces associations, la classe issue du sur-type joue le role de subor- 
donnee, et celle issue du sous-type celui d'agregat. Dans PiloteWeb, la classe 
partenai re est la classe subordonnee. 

• La multiplicite du role subordonne est egale a 1 et celle du role agregat est egale a *. 
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• Le nom du role subordonne doit etre representatif des donnees des sous-types 
mises en commun par la generalisation. Dans le cas de PiloteWeb, la classe 
partenai re joue le role fichePartenai re parce qu'on a juge que ce nom repre- 
sentait bien l'ensemble des donnees quelle generalise. 

La transformation des sur-types et sous-types en classes concretes est la solution 
retenue pour la suite de notre exemple PiloteWeb. Elle simplifie la representation en 
XML du modele logique en evitant de recourir aux techniques d'extension ou de res- 
triction de type de XML Schema. 

Cette solution est presentee a la figure 3-5. 



Figure 3-5 
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Modeles et espace de noms 

La premiere phase d'analyse des modeles logiques a permis d'identifier les modules 
de donnees a l'aide de paquetages UML (sites, pilotes, restaurants, aeroclubs, etc., 
des figures 3-1, 3-2 et 3-5) et de leurs dependances les uns par rapport aux autres. A 
la figure 3-6, vous verrez comment nous les regroupons en un paquetage unique 
representant finalement le modele logique global de PiloteWeb. 

C'est ce paquetage final qui porte l'ensemble du vocabulaire de PiloteWeb. II joue 
done le role d'espace de noms. Aussi percoit-on les deux fonctions du concept de 
paquetage d'UML : 

• L'une consiste a definir les frontieres des modules de donnees : il s'agit des paque- 
tages individuels, sites, pilotes, restaurants, etc. 

• L' autre consiste a definir l'espace de noms de l'application : il s'agit du paquetage 
baptise PiloteWeb: : Modeles logiques de donnees de la figure 3-6. A ce paque- 
tage est attribue un UPJ qui servira d'espace de noms XML, par exemple : 
http://www.piloteweb.com/2005. 
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Figure 3-6 Paquetages de PiloteWeb 
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VOCABULAIRE Objets de modelisation 

Un objet de modelisation est pour UML tout constituant d'un paquetage. Plus precisement, UML utilise la 
terminologie d'« element de modelisation ». Or, nous avons considere que cette terminologie pouvait 
preter a confusion avec la notion d'element de XML. Aussi avons-nous choisi d'utiliser le mot objet a la 
place du mot element. 



Pour indiquer comment chacune de ces deux fonctions est mise en oeuvre dans le 
modele UML, il faut que Ton precise les notions d'objets de modelisation, detenus et 
importes. UML fait la distinction entre les objets de modelisation detenus par un 
paquetage et ceux importes par un paquetage. Seuls les noms des elements detenus 
font partie de l'espace de noms defini par le paquetage. Les elements importes pro- 
viennent d'autres paquetages dont ils conservent l'espace de noms. 



VOCABULAIRE Objets de modelisation detenus par un paquetage 

On dit d'un objet de modelisation qu'il est detenu par un paquetage quand son nom appartient a 
l'espace de noms defini par le paquetage. Un objet de modelisation ne peut etre detenu que par un et un 
seul paquetage. Lorsque le paquetage est supprime, les objets de modelisation qu'il detient le sont aussi. 
Dans le cadre de la modelisation de donnees, les objets de modelisation qui peuvent etre detenus par un 
paquetage sont les classes, les associations et les generalisations. 



VOCABULAIRE Objets importes par un paquetage 

On dit d'un objet de modelisation qu'il est importe dans un paquetage quand son nom est detenu par un 
paquetage different de celui qui I'importe. On dit aussi de ces objets qu'ils sont references. Lorsque le 
paquetage qui fait I'import est supprime, les objets importes ne sont pas pour autant supprimes, seules 
leurs references disparaissent. 

Dans le cadre de la modelisation de donnees, les objets de modelisation qui peuvent etre importes par un 
paquetage sont les classes, les associations et les generalisations. 



Les notions de detention et d'importation permettent de regler la gestion des espaces 
de noms a partir du modele logique. Une bonne regie de modelisation consiste a 
separer les paquetages qui jouent le role d'espaces de noms de ceux qui jouent le role 
de modeles de donnees. Les paquetages « espaces de noms » sont les detenteurs des 
classes, associations, generalisations, ainsi que des paquetages decrivant les modeles 
de donnees. Les paquetages de type « modeles de donnees » n'utilisent que le meca- 
nisme d'import pour determiner leur contenu. 

Dans PiloteWeb, le paquetage logique global fait office d'espace de noms. II detient 
en consequence toutes les classes et associations, comme cela apparait a la figure 3-6. 
Les sous-paquetages sites, pilotes, partenaires, etc., ne detiennent pas de classes ou 
associations et, a ce titre, ne sont pas des espaces de noms. Ils indiquent les classes et 
associations qui font partie de leur perimetre. 
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Le mecanisme d'importation est malheureusement souvent laisse pour compte. Les 
concepteurs UML privilegient generalement le mecanisme de detention pour ranger 
les classes dans les paquetages ; ils ignorent le mecanisme d'import. Ainsi la classe 
pi Tote appartient-elle au paquetage pi Totes. Le defaut de cette approche est de 
multiplier les espaces de noms puisque dans UML tout paquetage detenteur est en 
meme temps espace de noms pour les objets de modelisation qu'il detient. En suivant 
cette approche, nous aurions des espaces de noms pour les sites, pilotes, aerodromes, 
etc., ce qui rendrait la correspondance avec XML pour le moins complexe car il nest 
pas recommande, avec XML Schema, de multiplier le nombre des espaces de noms 
d'une application. 

Dans une bonne analyse, l'espace de noms definit le champ semantique du domaine 
etudie, c'est-a-dire les frontieres de vocabulaire. Dans le cas PiloteWeb, on ne desire pas 
creer des vocabulaires distincts, l'un pour les pilotes, 1' autre pour les aerodromes, etc. 
Dans le perimetre de notre etude, on se borne a etablir le vocabulaire de PiloteWeb. 

Dans le passage a XML, seul le paquetage PiloteWeb: : Model es logiques de 
donnees donne lieu a un espace de noms. En fonction des choix d'implementation 
physique, on pourra disposer d'un seul fichier schema regroupant tous les sous- 
paquetages, ou d'autant de fichiers schemas qu'il y a de sous-paquetages : si tes . xsd, 
pilotes.xsd, etc. 

Toutes les classes detenues par le paquetage global vont donner lieu a des elements 
globaux dans le schema XML. Cependant, certaines classes hont pas vocation a 
devenir des elements globaux parce qu'elles n'ont qu'un emploi localise. C'est par 
exemple le cas de la classe photo, qui n'intervient que dans le cadre de la definition de 
la classe site. De meme, certains types de donnees n'ont de cas d'emploi que pour 
un seul attribut d'une classe, par exemple le type de donnees format, qui nest utilise 
que pour 1' attribut format de la classe photo. Dans ces cas d'utilisation locaux d'une 
classe ou d'un type de donnees, il faut pouvoir changer leur detenteur. Au lieu de les 
faire detenir par un paquetage, il est envisageable de les faire detenir par une classe. 
Cette classe detentrice joue alors elle-meme un role d'espace de noms. Ainsi la classe 
photo est-elle detenue par la classe site et le type de donnees format est lui-meme 
detenu par la classe photo. II en decoule la regie suivante : 

• Les classes et types de donnees utilises localement par rapport a une classe doi- 
vent etre detenus localement par cette classe. 

• Le nom de la classe detentrice joue alors le role d'espace de noms local pour les 
classes et types de donnees ainsi detenus. 

La notation UML represente ces relations de detention par une ligne avec un orne- 
ment du cote du detenteur en forme de cercle barre d'une croix (figure 61 dans la 
specification UML 2.0). 
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Tableau 3-4 Detention locale de classes 



Modele logique UML 

Classes locales 



Modeles logiques de 
donnees 



site 



~rs 



photo 



ntmnorn 
tain at: format 



~w 



E ■ . 1 1 i* r<i'. J I : 

format 
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Representations XML 

Types locaux 

<xs: element name="site"> 
<xs : compl exType> 

<xs: attribute name="nom"/> 
<xs:sequence> 

<xs: element name="Photo"> 
<xs : compl exType> 

<xs: attribute name="nom"/> 
<xs: attribute name="format"> 
<xs: simpleType> 

<xs: restriction base="xs:string"> 
<xs:enumeration value="png"/> 
<xs:enumeration value="gif"/> 
<xs:enumeration value="jpg"/> 
</xs: restriction> 
</xs : si mpl eType> 
</xs:attribute> 
</xs : compl exType> 
</xs:element> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 
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Classc, type XML et element XML 

Dans cette section, nous allons preciser les correspondances existant entre les classes 
UML et les elements et types XML. L'un des points dont nous allons particuliere- 
ment tenir compte est la double fonction des classes UML : 

• Donner les caracteristiques d'un objet. Ainsi, la classe site a comme caracteristi- 
ques un nom, des positions geographiques (x,y) et une description visuelle qui 
prend la forme d'une photo. 

• Donner une existence a une liste d'objets. Ainsi, le modele logique de PiloteWeb 
ou la classe si te est une classe concrete (figure 3-1) indique qu'il existe des occur- 
rences precises de site, par exemple : le Mans-Arnage, position(x=47.9486, 
y=-0.2016), photo (nom="lemans . jpg" format="jpg") ; Toussus-le Noble, 
positi on (x=48. 7494, y=-2. 1108) , photo (nom=" toussus.jpg" ,format="jpg") ; etc. 

Nous avons vu avec la classe partenai re que les generalisations peuvent introduire 
des ambiguites sur le mode d'existence des objets : un partenaire existe-t-il sous la 
forme d'un partenaire, d'un restaurant, d'un aerodrome ou d'un aeroclub ? Nous 
avons vu comment lever ces ambiguites en indiquant les classes qui sont abstraites et 
celles qui sont concretes. 

De son cote, XML Schema fait une distinction explicite entre la definition des caracte- 
ristiques et la declaration des listes possibles d'occurrences. La definition des caracteris- 
tiques est fake au moyen des types, celle des occurrences au moyen des elements. On 
dit ainsi qu'il peut y avoir des elements site de type siteType. Le type siteType est 
soit explicite done global, soit implicite done local (auquel cas, il n'a pas de nom). 

A partir des explications precedentes, il apparait que toute classe UML donne lieu a 
la fois a un type XML et a un element XML, a l'exception des classes abstraites qui 
ne donnent lieu qua un type global. 

• Classe concrete => element XML + type XML. 

• Classe abstraite => type XML global. 

II faut maintenant determiner si 1' element XML correspondant a une classe concrete 
est global ou local. Nous avons vu dans la section sur les espaces de noms que toute 
classe detenue par le paquetage ayant la fonction d'espace de noms donnait lieu a un 
element global. Au contraire, toute classe detenue par une autre classe donne lieu a 
un element local. 

• Classe detenue par le paquetage d'espace de noms => element XML global. 

• Classe detenue par une autre classe => element XML local. 

La regie concernant le caractere global ou local des types XML correspondant aux 
classes concretes est plus delicate. Toute classe d'une generalisation se traduit par un 
type XML global. En effet, les mecanismes de derivation de XML Schema - les 
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seuls a pouvoir traduire le concept de generalisation de UML - n' existent que pour 
des types globaux de XML Schema. Dans le cas de PiloteWeb ou la classe 
partenai re est une generalisation des classes restaurant, "loueur et aeroclub, on la 
traduira par le type global partenai reType : 

<xs:complexType name="partenai reType"> 
<xs:sequence> 

<xs: element ref="l oca! i sat ion Partenai re"/> 
<xs:element name="adresse" type="adresse"/> 
<xs: element name="telephone" type="telephone"/> 
</xs:sequence> 
</xs : compl exType> 

Pour les autres cas, il y a deux ecoles : celle des methodes de transformation automa- 
tique et celle cherchant a optimiser le schema XML. Les outils de transformation 
des modeles de classes en schemas XML privilegient la creation systematique de 
types globaux. C'est le cas des regies de transformation adoptees a l'OMG pour 
XMI 2.0. Ces regies sont exprimees en BNF. La regie 3 (tableau 3-5) indique qu'une 
classe est representee par une declaration de type et une declaration d'element. 

Tableau 3-5 Declaration de production de schema dans la specification XMI de l'OMG 

Extrait de la syntaxe EBNF Description 

3. ClassSchema : := 4:ClassTypeDef 3. The class schema contribution consists 

5 :ClassElementDef of a type declaration based on the 

attributes and references of the class, 
and an element declaration for the Class 
itself. 

Dans un schema XML, la classe est transposee au moyen d'une 
definition de type, basee sur les attributs et references de la 
classe, et d'une definition d'element pour la classe elle-meme. 



La seconde ecole ramene le nombre de types globaux aux seuls types reutilises par 
plusieurs elements. Lobjectif est de diminuer le volume des schemas et de limiter les 
consequences de 1'utilisation d'espaces de noms. 

Une fois que Ton a defini les elements et les types du schema XML issus directement 
de l'analyse des classes UML, il faut determiner s'il y a lieu d'ajouter des elements 
XML supplementaires pour gerer les listes d'elements : faut-il des elements photos, 
sites, etc. ? 

Les elements pour lesquels cette organisation en liste est necessaire sont les classes 
entites des modules de donnees. Chaque classe entite d'un module de donnees a voca- 
tion a etre adressee par d'autres classes appartenant a d'autres modules de donnees. 
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II en decoule la regie suivante : 

• A chaque classe entire doit correspondre un element XML gerant la collection 
des occurrences de cette classe. 

• Par convention, le nom de l'element XML gerant la collection des occurrences est 
le nom de la classe auquel on ajoute un « s » comme indique a la figure 3-6. 

• Les modules de donnees contiendront les occurrences de leurs classes entites. 
Lanalyse physique des modeles de donnees (voir chapitre 4) permettra de savoir 
si les modules de donnees seront geres dans un meme et seul document XML, ou 
au contraire dans differents documents. 

Tableau 3-6 Declaration de collection d'elements 



Modele UML 

Un module et sa classe entite 



sites 



site 



position: position 



Representations XML 

Module et collection d'elements 

<xs:element name="site" type="pw:siteType"/> 

<xs:element name="sites"> 
<xs : compl exType> 
<xs:sequence> 

<xs:element ref="pw:site" 

maxOccurs="unbounded"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 



Les elements XML tels que sites n'ont done pas de correspondance directe en tant 
que classes dans le modele UML. lis sont la manifestation d'une collection d'ele- 
ments organises en module de donnees. 

Outre la gestion des collections, il faut permettre l'identification des elements XML 
contenus dans ces collections. On peut y proceder soit au travers de caracteristiques 
propres a la classe, tel un attribut nom, soit au moyen d'un mecanisme standard utili- 
sant un code d'identification attribue automatiquement. C'est la solution qui est 
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retenue dans PiloteWeb. Dans le schema XML, les elements site, pi Tote, 
partenaire, restaurant, aeroclub et aerodrome ont tous un attribut id de type 
xs:ID. 

<xs: element name="site"> 
<xs : compl exType> 
<xs:sequence> 

</xs:sequence> 

<xs:attribute name="id" type="xs:ID"/> 

<xs: attribute ref="pw:nom"/> 
</xs : compl exType> 
</xs:element> 



Gestion des associations 

En etudiant les associations, nous allons completer nos analyses sur : 

• les collections d'elements XML ; 

• la definition du type des elements XML. 

Cependant, pour apprehender ces sujets, revenons a la definition d'une association et 
aux objets qui la composent : 

• Les references d'objets permettent de designer un objet par un pointeur, une 
adresse ou tout autre mecanisme de referencement. 

• Les significations donnees a ces references. Par exemple, dans 1' association entre 
la classe site et la classe pi Tote, la signification attribute a la reference qui per- 
met de localiser un pilote au moyen d'une reference a un site est 
localisation Pi Tote. 

Pour qu'il y ait association, il faut d'abord pouvoir faire reference a des objets identi- 
fiables et adressables. Les associations organisent ensuite les references aux objets en 
leur attribuant des roles afin d'en indiquer la signification comme nous l'illustrons a la 
figure 3-7. Lassociation precise ainsi 1' existence de la liaison entre deux objets et la 
raison d'etre de cette liaison ; c'est ce que Ton appelle doctement la semantique des 
liens. Dans PiloteWeb, l'association entre la classe pilote et la classe site indique 
qu'il est possible de referencer des sites au titre du role 1 ocal i sati onPi 1 ote et qu'il est 
aussi possible de referencer des pilotes au titre du role piloteLocalise. L'association 
indique en outre que les roles 1 ocal i sati onPil ote et piloteLocalise vont de pair. 

Outre la semantique des liens, les associations permettent de decrire tous les modes 
de navigation du lien ; les associations ne sont pas directionnelles, seul l'usage que 
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Ton en fait Test. Ainsi peut-on naviguer des pilotes localises vers les sites de localisa- 
tion, aussi bien que des sites de localisation vers les pilotes localises. 



Figure 3-7 

Association et references 
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Cependant, la gestion des references requise pour une mise en ceuvre complete des 
associations est le plus souvent complexe a realiser car cela demande de prendre en 
compte tous les modes de traversee des associations. Dans les modeles physiques, 
cela suppose que Ton dispose d'un mecanisme gerant explicitement les associations. 
Par exemple, dans un document XML, il faudrait disposer d'un element specifique 
pour chaque association, comme indique dans l'exemple simplifie ci-apres : 

<objetl> 

</objetl> 
<objet2> 

</objet2> 

association objetl-objet2> 

<refObjet id=objetl> 

<refObjet id=objet2>... 
</association> 

Pour les applications standards, un tel choix d'implementation est bien trop couteux : 
pour passer de l'objet 1 a l'objet2, il faut effectuer trois navigations: objetl -> 
association(refObjet id=objetl) -> association(refObjet id=objet2) -> objet2. 
Pour simplifier la navigation, l'element association est supprime, chacune des references 
« migrant » alors dans les objets concernes comme indique dans l'exemple suivant : 

<objetl> 

<refObjet id=objet2>... 

</objetl> 
<objet2> 

<refObjet id=objetl> 

</objet2> 
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Le cas general est presente a la figure 3-8 : 



Figure 3-8 

References ayant migre 
dans les objets 



Association 



Objet 1 




Objet 2 



Reference a I'objet 1 



Objet 1 




Objet 2 



Reference a I'objet 2 

Les regies de transfert des associations dans les objets dependent de l'analyse du type 
des associations comme nous allons le voir. 

Les associations de composition 

Les associations de composition sont, comme nous l'avons dit en debut de chapitre, des 
associations de type tout/partie exprimant une subordination forte entre deux classes 
comme l'indique la figure 3-9. Le role representant le tout est le role de composition. II 
designe la classe subordonnante dans l'association. Lautre role represente les parties ; 
c'est le role de subordination. II indique la classe subordonnee dans l'association. 
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Figure 3-9 Association de composition 
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Dans une composition, les occurrences de la classe subordonnee ne peuvent exister 
sans l'occurrence de la classe subordonnante. Ainsi, dans PiloteWeb, les occurrences 
de la classe photo n' existent que lorsque celles de la classe site existent. Cela indique 
que les associations de composition doivent se traduire dans les documents XML par 
des imbrications d'elements. II en resulte les regies de transformation suivantes : 

• L'association de composition se traduit par la declaration d'un ou plusieurs ele- 
ment(s) dans la definition du type de la classe subordonnante de ces elements. Par 
exemple, le type representant la classe site contient la declaration de l'element 
photo (et non un lien a cet element) qui est subordonne a cette classe. 

• L'element prend pour nom celui du role de subordination. Dans l'exemple prece- 
dent, le nom du role de subordination est le meme que le nom de la classe subor- 
donnee a savoir photo. Le type XML de cet element est celui de la classe subor- 
donnee et pourra etre defini localement ou globalement. Dans notre exemple, 
selon que la classe photo a donne lieu a un type global ou local, l'element photo 
sera defini globalement ou localement (le tableau 3-7 contient des exemples de 
ces deux cas). 

• Comme valeurs de ses indicateurs d'occurrence, on reprend celles donnees au 
subordonne: i'attribut minOccur (respectivement maxOccur) de XML Schema 
correspond a la multiplicite minimale (respectivement maximale) du subordonne 
dans un modele UML. Dans notre exemple, la multiplicite 1 de la classe subor- 
donnee photo indique que toute occurrence de la classe site contiendra une et 
une seule occurrence de la classe photo. Dans le schema XML, nous avons done 
mis a 1 les multiplicites de l'element photo : minOccurs="l" et maxOccurs="l". 

En ce qui concerne le sens de parcours de l'association, aussi bien dans le sens subor- 
donnant vers subordonne que l'inverse, XML permet de 1' assurer sans aucune diffi- 
culte par la simple exploitation des mecanismes de parcours d'arbre XML : 
element.enfant(x)< — > element.parent. 







Tableau 3-7 Association de type composition 
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Tableau 3-7 Association de type composition 
Representations XML 



Imbrication d'element avec une declaration de type local 

<xs: element name="site"> 
<xs : compl exType> 
<xs:sequence> 

<xs: element name="photo" minOccurs="l" maxOccurs="l"> 
<xs : compl exType> 

<xs: attribute name="nom"/> 
<xs: attribute name="format"> 
<xs: simpleType> 

<xs: restriction base="xs:string"> 
<xs:enumeration value="png"/> 
<xs:enumeration value="gif"/> 
<xs:enumeration value="jpg"/> 
</xs: restriction> 
</xs : si mpl eType> 
</xs:attribute> 
</xs : compl exType> 
</xs:element> 

</xs:sequence> 

</xs : compl exType> 
</xs:element> 

Imbrication d'element avec une declaration de type global 

<xs: compl exType name="photoType"> 

</xs : compl exType> 

<xs: element name="site"> 
<xs : compl exType> 

<xs: attribute name="nom"/> 
<xs:sequence> 
<xs: element name="photo" 

type="photoType" 
minOccurs="l" 
maxOccurs="l"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 
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Les associations d'agregation 
Introduction 

Les associations d'agregation sont des associations de type tout/partie exprimant une 
subordination faible entre deux classes comme l'indique la figure 3-10. Le role repre- 
sentant le tout est le role d'agregation. II designe la classe subordonnante dans 1' asso- 
ciation. Lautre role represente les parties ; c'est le role de subordination. II indique la 
classe subordonnee dans l'association. Dans une agregation, contrairement a la com- 
position, les occurrences de la classe subordonnee peuvent exister independamment 
de l'occurrence de la classe subordonnante. Ainsi, dans PiloteWeb, les occurrences 
de la classe site peuvent exister independamment de celles de la classe pi Tote. Pour 
autant, les sites font partie de la definition d'un pilote. 
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Figure 3-10 Association d'agregation 
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Regies par defaut 

Par defaut, la traduction en objets XML des associations d'agregation obeit aux 
regies suivantes : 

• Chaque role de subordination donne lieu a la declaration d'un element dans la 
definition du type XML representant la classe subordonnante. Par exemple, le 
type XML representant la classe pi 1 ote contient une declaration d'element pour 
representer l'objet associe site. 

• Le nom donne a cet element est celui du role qu'il a dans l'association. Dans notre 
cas, l'element declare ne sera pas site mais localisation Pi Tote. 

• Les valeurs des indicateurs d'occurrence de l'element XML sont celles de la mul- 
tiplicite du role qui lui correspond : l'attribut mi nOccur (respectivement maxOccur) 
de XML Schema aura la valeur de la multiplicite minimale (respectivement maxi- 
male) du modele de classe UML. 

• La caracteristique particuliere de 1' agregation est que l'objet associe peut avoir une 
vie propre independamment de l'objet qui l'agrege. Cela signifie qu'il revient a la 
classe agregeant de gerer le lien qui l'unit a l'objet subordonne, et pas l'inverse. 
Ainsi, les agregations traduisent implicitement une « navigation semantique » 
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entre les objets par la seule existence de ce lien directif qui, pour former l'agrega- 
tion, va de la classe agregeant a l'objet agrege. La figure 3-11 illustre cette carac- 
teristique particuliere des agregations. 



Figure 3-11 

Agregation et navigabilite 
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non prise en compte 




Reference a l'objet 2 



Objet 
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XML et XML Schema ne proposant pas intrinsequement une methode de represen- 
tation des references, ou liens, il est conseille, au niveau du modele logique, de creer 
un type XML permettant de differer le choix de la solution qui sera finalement 
retenue pour representer ces references. Dans cette section, nous proposons un type 
XML appele entityRef base sur XLink : 

<xs:complexType name="entityRef"> 

<xs:attribute ref="xl :type" fixed="simp1e"/> 

<xs: attribute ref="xl :href" use="requi red"/> 
</xs : compl exType> 

Dans l'exemple decrit au tableau 3-8, la reference au site depuis 1' element pi Tote 
utilise pour l'element local isationPilote le type entityRef. C'est un nom gene- 
rique qui peut representer toute sorte de mecanisme de referencement d'entites. Lors 
de la conception du modele physique, ce type sera adapte aux options de stockage 
physique choisies. 

En lieu et place d'elements, on peut utiliser des attributs pour representer les refe- 
rences. Les regies precedemment edictees deviennent alors : 

• Chaque role que prend l'objet subordonne par rapport a un subordonnant se tra- 
duit par un attribut dans le type XML representant la classe qui subordonne. Par 
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exemple, le type XML de la classe pi 1 ote aura dans ce cas un attribut dont le 
nom est 1 ocal i sati onPi 1 ote (et non un element comme dans le cas precedent). 

• Le type de cet attribut sera egalement le type generique enti tyRef . 

Lavantage de la gestion des references par attribut, c'est sa simplicite. Ses inconve- 
nients n'en sont pas moins nombreux : 

• II n'est pas possible de controler les indicateurs d'occurrence. 

• Le controle de la structure des references complexes est limite aux possibilites 
offertes par les types simples de XML. 



Tableau 3-8 Association de type agregation 



Modele UML 
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Representations XML 

Reference au moyen d'un element XML 

<xs:complexType name="enti tyRef "> 

<xs: attribute ref="xl :type" fixed="simple"/> 
<xs: attribute ref="xl :href" use="requi red"/> 

</xs : compl exType> 

<xs:element name="pilote"> 
<xs : compl exType> 
<xs:sequence> 

<xs : el ement name="l ocal i sati onPil ote" 

type="pw: enti tyRef "/> 
</xs :sequence> 

<xs: attribute name="emai"l " type="xs: string"/> 
<xs: attribute name="pwd" type="xs:string"/> 
</xs : compl exType> 
</xs:element> 
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Tableau 3-8 Association de type agregation 



Reference au moyen d'un attributXML 

<xs : si mpl eType name="enti tyRef "> 

<xs: restriction base="xs:string"/> 
</xs : si mpl eType> 

<xs:element name="pi"lote"> 
<xs : compl exType> 

<xs: attribute name="emaiT' type="xs: string"/> 
<xs: attribute name="pwd" type="xs:string"/> 
<xs : attri bute name="l ocal i sationPi 1 ote" 
type="pw:enti tyRef "/> 
</xs : compl exType> 
</xs:element> 



Prise en compte des modules de donnees 

La prise en compte des modules de donnees apporte une dimension supplemental 
a la mise au point du modele logique et permet d'affiner la mise en oeuvre des pre- 
miere et derniere regies indiquees precedemment : 

• Changement de la regie de transformation de l'association : lorsque la classe 
subordonnee n'est la classe entite d'aucun autre paquetage, alors l'agregation est 
traitee comme une composition. Par exemple, dans PiloteWeb, on aurait pu ne 
pas creer le paquetage sites dans lequel la classe site est une classe entite. Dans 
ce cas, les types XML auxquels ont donne lieu les classes pi 1 ote et aerodrome 
auraient inclus hierarchiquement la definition de site. En d'autres termes, les 
occurrences de site auraient ete gerees sous les elements pi Tote et aerodrome. 

• Changement de la regie de navigabilite : lorsque le paquetage, ou module de don- 
nees, d'une classe entite comprend explicitement une association ou la classe 
entite joue le role de subordination, cela vient modifier la regie standard sur la 
navigabilite. La reference a l'agregat doit alors etre geree. Dans l'exemple presente 
dans le tableau 3-9, le paquetage sites de la classe site inclut l'association entre 
site et partenaire. Cela indique que la definition de site doit aussi inclure les 
references vers les partenaires, meme si la classe site est la classe subordonnee 
dans cette association. Lobjectif est de pouvoir forcer la navigation vers l'agregat 
dans le contexte d'un module de donnees specifique sans avoir a remettre en cause 
globalement cette agregation. 
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Tableau 3-9 Module de donnees et agregation 



Modele UML 

Agregation 



nom:nom 
+position:position 



localis/ionPartenaire 1 



sites 



site 
photographie 1_ 



0..1 



photo 




photo 



nom:nom 
form at: form at 



A partenaire syr site 



+Adres5 
+telephone:telephone 



Representations XML 

Reference au moyen d'un element XML 



<xs:complexType name="entityRef"> 

<xs:attribute ref="xl :type" fixed="simple"/> 
<xs: attribute ref="xl :href" use="requi red"/> 
</xs : compl exType> 
<xs: element name="site"> 
<xs : compl exType> 

<xs: attribute name="nom"/> 
<xs:sequence> 

<xs: element name="photo" 

type="photoType" 
minOccurs="l" 
maxOccurs="l"/> 
<xs : el ement name="partenai resurSi te" 
type="pw : enti tyRef " 
minOccurs=" unbounded " 
maxOccurs="unbounded"/> 
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Tableau 3-9 Module de donnees et agregation 



</xs:sequence> 
</xs : compl exType> 
</xs:element> 

<xs:element name="pilote"> 
<xs : compl exType> 
<xs:sequence> 
</xs:sequence> 

<xs: attribute name="ema"M " type="xs: str"ing"/> 
<xs: attribute name="pwd" type="xs:string"/> 
</xs : compl exType> 
</xs:element> 



En complement de l'analyse des associations, l'analyse des modules de donnees 
apporte done quelque lumiere sur le contour d'une classe et sur la localisation des 
occurrences. A partir d'un meme graphe de classes, il est possible de specifier plu- 
sieurs modes de decoupage. Cela est particulierement utile lorsqu'une partie seule- 
ment du modele de donnees doit etre prise en compte, par exemple pour un transfert 
d'un paquet de donnees d'un systeme vers un autre, car la notion de module corres- 
pond, in fine, a la facilite avec laquelle on pourra isoler des paquets de donnees afin 
de les manipuler independamment du reste de 1' application : e'est typiquement le cas 
lorsque des donnees doivent etre echangees entre applications. 

Les associations simples 

Dans les associations simples, chaque classe a un role de poids equivalent. Cela veut dire 
qu'il n'y a pas de hierarchie entre les objets et que l'association a une autonomic propre ; 
elle nest pas assujettie a l'une ou l'autre des classes. En XML, on traitera ce type disso- 
ciation soit comme un element autonome contenant des references aux objets qui fer- 
ment l'association, soit comme des references croisees entre les objets associes. 

En optant pour la premiere solution d'un element autonome pour l'association, on 
s'assure la plus grande flexibilite et la meilleure coherence dans la gestion des liens. 
Lorsque l'association est un element autonome, les references aux objets sont gerees 
conjointement sous le meme element XML. Dans l'exemple presente au 
tableau 3-10, on a ajoute une nouvelle association entre la classe pi 1 ote et la classe 
site. Cette association indique les evaluations donnees par les pilotes sur la qualite 
des sites. L'association est porteuse de deux attributs : note et commentaire. 
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Le tableau 3-10 donne aussi la representation XML de cette association sous forme 
d'un element autonome en appliquant les regies suivantes : 

• L' association est representee par un element XML. Le nom de l'element est celui 
de l'association. Dans l'exemple donne par le tableau 3-10, ce nom est 
eval uati onsi te. 

• Un element chapeau, reunissant toutes ces associations, gere la collection des 
occurrences d'association. Par codification, cet element a pour nom le nom de 
l'association suffixe d'un « s ». Dans notre exemple, il s'agit de l'element 
eval uati onsi tes. 

• Chaque role de l'association est represente par un sous-element de l'element 
representant l'association. Dans notre exemple, evaluationsite comprend les 
elements evaluateur et siteevalue correspondant respectivement au role de la 
classe pilote et a celui de la classe site. 

• Le type des elements representant les roles est entityRef, ou tout autre meca- 
nisme permettant le referencement d'element XML. 

Tableau 3-10 Association autonome 



Modele UML 


Association simple 
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Representations XML 


Association sous forme d'un element autonome 


<xs : el ement name="eval uati onsi tes"> 


<xs : compl exType> 


<xs: sequence> 


<xs : el ement name="eval uati onsi te" 


maxOccurs="unbounded"> 


<xs : compl exType> 
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<xs :sequence> 




<xs: element name= 


'evaluateur" 


type= 


'pw:entityRef "/> 


<xs: element name= 


'siteevalue" 


type= 


'pw:entityRef "/> 


<xs: element name= 


'note" 


type= 


'xs :integer"/> 


<xs: element name= 


'commentai re" 


type= 


'xs:string"/> 


</xs:sequence> 




</xs : compl exType> 




</xs:element> 




</xs :sequence> 




</xs : compl exType> 




</xs:element> 





On peut noter que la suppression d'un element evaluationsite entraine nativement 
celle des elements de reference aux objets sites et pilotes, ce qui simplifie la gestion 
de l'integrite referentielle. En revanche, le parcours des references est plus complexe : 
pour trouver les pilotes evaluateurs d'un site, il faut rechercher tous les elements 
evaluationsite ayant une reference siteevalue correspondant au site recherche. 
Pour chaque element evaluationsite trouve, il faut ensuite rechercher les elements 
pi 1 ote a partir de la reference donnee par 1' element eval uateur. 

I site -> evaluationsite. siteevalue -> evaluationsite. evaluateur -> pilote 

Certains modeles XML avances, comme TopicMap, considerent les associations 
comme des elements a part entiere. Ces modeles sont presentes dans le chapitre 10. 

Cependant, la difficulte de mise en ceuvre du parcours des associations conduit le 
plus souvent a decider de leur orientation physique. Un seul des roles est alors declare 
physiquement navigable, ce qui se manifeste, dans la notation UML, par une fleche 
du cote du role navigable (tableau 3-11). Les decisions sur la navigabilite peuvent 
etre prises assez tot dans la conception des modeles de donnees. Elles permettent de 
preciser une orientation du graphe des objets lorsque les caracteristiques d'orienta- 
tion semantiques (agregation, composition) ne sont pas specifiees. 

Dans la representation XML, on fait alors « migrer » les elements de l'association 
dans 1' element dont le role n'est pas navigable. Lorsque l'association n'est pas por- 
teuse d'attribut, seule la reference a l'objet navigable est migree. Le tableau 3-11 
donne la representation XML correspondante. 
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Tableau 3-11 Association autonome 
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Representations XML 

Association sous forme d'element migrant 
<xs: element name="site"> 
<xs : compl exType> 
<xs:sequence> 



<xs : el ement name="eval uati onsi te" 
maxOccurs="unbounded"> 
<xs : compl exType> 
<xs:sequence> 

<xs: el ement name="evaluateur" 

type="pw : enti tyRef "/> 
<xs: el ement name="note" 

type="xs : i nteger"/> 
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Tableau 3-11 Association autonome 



<xs: element name="commentai re" 
type="xs : stri ng"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 
<xs: element name="site"> 
<xs : compl exType> 
<xs:sequence> 

<xs: element name="evaluateur" 

type="pw:entityRef"/> 
maxOccurs="unbounded"> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 



Gestion des attributs 

Nous avons vu dans le chapitre 2 que certains attributs du modele de classe avaient 
un type simple, comme « chaine de caracteres », et que d'autres avaient un type com- 
pose, comme l'attribut position d'un site. Pour les attributs composes, la regie de 
transformation en XML est simple : ils donnent lieu a des types complexes compre- 
nant des sous-elements. 

Pour les attributs de type simple, il est plus difficile de statuer. Quelques bonnes pra- 
tiques peuvent cependant etre etablies : 

• Les attributs identifiants (par exemple i d) ou candidats identifiants (par exemple 
le nom) sont representes sous forme d'attributs XML. 

• Les attributs textes de longueur significative, comme les descriptions ou com- 
mentaires, sont representes par des elements. 

• Les attributs ayant une multiplicite superieure a 1 sont representes par des ele- 
ments. 

• Pour les autres attributs, le choix de l'implementation XML sous forme d'element 
ou d'attributs ressortit a une politique globale de gestion de schema. Une politi- 
que « conservatrice » optera pour l'utilisation d'elements car elle permet une plus 
grande evolutivite. Une politique « d'economie » optera pour l'utilisation d'attri- 
buts XML, moins verbeuse que l'usage des elements. 
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Le schema logique de ('application PiloteWeb 

En appliquant les regies enoncees depuis le debut du chapitre a l'ensemble du modele 
conceptuel de PiloteWeb, on obtient les modeles logiques et leurs correspondances 
en schemas XML presentes dans cette section. 

Module de donnees « sites » 
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Figure 3-12 Module de donnees « sites » 



II existe des occurrences independantes et referencables de sites. L'element site est 

done public. 

La liste des occurrences de sites est geree sous l'element global sites issu du 

paquetage sites. 

Par principe d'economie, le type de la classe site nest pas publie en dehors de 

l'element site. 

L'element site etant referencable, un attribut xsd : ID lui a ete automatiquement 

ajoute. 

Lattribut nom de site reference le type public nom. Le choix d'implementation de 

PiloteWeb est d'avoir un attribut nom global. 

Lattribut position est decompose et donne done lieu a un type complexe. 
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• Le type de donnees position est local a la classe site. II donne lieu a un type 
local de l'attribut position dans le modele XML. 

• La politique de PiloteWeb pour l'implementation des attributs simples est l'usage 
des attributs XML. Les attributs x et y n'etant pas identifiants, ils donnent lieu a 
des attributs XML. 

• La classe si te a une association de composition avec la classe photo, ce qui donne 
lieu a un sous-element photo dans l'element site. 

• La classe photo est declaree comme locale a la classe site. Le type de l'element 
photo est done declare comme local a l'element photo. 

• L'attribut nom de photo reference le type public nom. Le choix d'implementation 
de PiloteWeb est d'avoir un attribut nom global. 

• La politique de PiloteWeb pour Fimplementation des attributs simples est l'usage 
des attributs XML. L'attribut format donne lieu a un attribut XML. 

• Le type de donnees format est local a la classe photo. II donne lieu a un type local 
de l'attribut format dans le modele XML. 

<xs: element name="site"> 
<xs : compl exType> 
<xs:sequence> 

<xs:element name="position"> 
<xs : compl exType> 
<xs: sequence/> 

<xs: attribute name="x" type="xs :decimal"/> 
<xs: attribute name="y" type="xs :decimal"/> 
</xs : compl exType> 
</xs:element> 
<xs: element name="photo"> 
<xs : compl exType> 

<xs: attribute ref="pw:nom"/> 
<xs: attribute name="format" use="requi red"> 
<xs: simpleType> 

<xs: restriction base="xs:string"> 
<xs : enumeration value="png"/> 
<xs : enumeration value="gif"/> 
<xs : enumeration value="jpg"/> 
</xs : restri cti on> 
</xs : si mpl eType> 
</xs:attribute> 
</xs : compl exType> 
</xs:element> 
</xs:sequence> 
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<xs: attribute name="id" type="xs:ID"/> 
<xs:attn'bute ref="pw:nom"/> 
</xs : compl exType> 
</xs:element> 

<xs:element name="sites"> 
<xs : compl exType> 
<xs:sequence> 

<xs: element ref="pw:site"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 
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Figure 3-13 

Module de donnees « pilotes » 
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• II existe des occurrences independantes et referencables de pilotes. L'element 
pi 1 ote est done public. 

• La liste des occurrences de pilotes est geree sous 1' element global pilotes issu 
du paquetage pilotes. 

• Par principe d'economie, le type de la classe pi 1 ote n'est pas publie en dehors de 
l'element pi 1 ote. 

• L'element pi 1 ote etant referencable, un attribut xsd:ID lui a ete automatique- 
ment ajoute. 

• Lattribut nom de pi 1 ote reference le type public nom. Le choix d'implementation 
de PiloteWeb est d'avoir un attribut nom global. 
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Le type de donnees pwd (password) est local a la classe pi Tote. II donne lieu a un 

type local de l'attribut pwd dans le modele XML. 

Le type de donnees emai 1 est local a la classe pi 1 ote. II donne lieu a un type local 

de l'attribut emai 1 dans le modele XML. 

La classe pi 1 ote a une association d'agregation avec la classe site, ce qui donne 

lieu a un sous-element localisationpilote dontle type est entityRef. 

<xs: element name="pilote"> 
<xs : compl exType> 
<xs:sequence> 

<xs : el ement name="l ocal i sati onpi 1 ote" type="pw : enti tyRef "/> 
</xs:sequence> 

<xs: attribute name="id" type="xs:ID"/> 
<xs: attribute ref="pw:nom"/> 
<xs: attribute name="pwd"> 
<xs:simpleType> 

<xs: restriction base="xs:string"/> 
</xs : si mpl eType> 
</xs:attribute> 
<xs: attribute name="email "> 
<xs :simpleType> 

<xs: restriction base="xs:string"/> 
</xs : si mpl eType> 
</xs:attribute> 
</xs : compl exType> 
</xs:element> 

<xs: el ement name="pilotes"> 
<xs : compl exType> 
<xs:sequence> 

<xs:element ref="pw:pilote"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 



Module de donnees « aerodromes » 

• II existe des occurrences independantes et referencables d'aerodromes. L'element 
aerodrome est done public. 

• La liste des occurrences d'aerodromes est geree sous l'element global aerodromes 
issu du paquetage aerodromes. 

• Par principe d'economie, le type de la classe aerodrome n'est pas publie en dehors 
de l'element aerodrome. 
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Figure 3-14 
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L'element aerodrome etant referencable, un attribut xsd:ID lui a ete automati- 

quement ajoute. 

L' attribut nom d'aerodrome reference le type public nom. Le choix d'implementa- 

tion de PiloteWeb est d'avoir un attribut nom global. 

Le type de donnees code est local a la classe aerodrome. II donne lieu a un type 

local de 1' attribut code dans le modele XML. 

Le type de donnees frequence est local a la classe aerodrome. II donne lieu a un 

type local de 1' attribut emai 1 dans le modele XML. 

La classe aerodrome a une association d'agregation avec la classe site, ce qui 

donne lieu a un sous-element local isationAerodrome dont le type est 

entityRef. 

<xs: element name="aerodrome"> 
<xs : compl exType> 
<xs:sequence> 

<xs : el ement name="l ocal i sati onAerodrome" type="pw : enti tyRef "/> 
</xs:sequence> 

<xs: attribute name="id" type="xs:ID"/> 
<xs: attribute ref="pw:nom"/> 
<xs: attribute name="code"> 
<xs:simpleType> 

<xs: restriction base="xs:string"/> 
</xs : si mpl eType> 
</xs:attribute> 
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<xs : attri bute name="f requence"> 
<xs:simpleType> 

<xs: restriction base="xs:string"/> 
</xs : si mpl eType> 
</xs: attri bute> 
</xs : compl exType> 
</xs:element> 

<xs: element name="aerodromes"> 
<xs : compl exType> 
<xs:sequence> 

<xs :element ref="pw:aerodrome"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 



Module de donnees « partenaires 



Figure 3-15 
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• II existe des occurrences independantes et referencables de partenai res. L'ele- 
ment partenai re est done public. 

• La liste des occurrences de partenaire est geree sous l'element global 
partenai res issu du paquetage partenai res. 

• Par principe d'economie, le type de la classe partenai re nest pas publie en 
dehors de l'element partenai re. 

• L'element partenaire etant referencable, un attribut xsd:ID lui a ete automati- 
quement ajoute. 

• Le type de donnees adresse est global et est utilise comme type pour l'attribut du 
meme nom de l'element partenai re dans le modele XML. 
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Le type de donnees telephone est global et est utilise comme type pour l'attribut 

du meme nom de i'element partenai re dans le modele XML. 

La classe partenai re a une association d'agregation avec la classe site, ce qui 

donne lieu a un sous-element local isationPartenai re dont le type est 

entityRef. 



<xs: element name="partenai re"> 
<xs : compl exType> 
<xs:sequence> 

<xs : el ement name="l ocal i sati on Partenai re" type="pw: enti tyRef "/> 
</xs:sequence> 

<xs: attribute name="id" type="xs:ID"/> 
<xs:attribute name="adresse" type="pw:adresse"/> 
<xs:attribute name="telephone" type="pw: telephone"/> 
</xs : compl exType> 
</xs:element> 

<xs : el ement name="partenai res"> 
<xs: compl exType> 
<xs:sequence> 

<xs: el ement ref="pw: partenai re"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 
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Figure 3-16 

Module de donnees 
« restaurants » 
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II existe des occurrences independantes et referencables de restaurants. Lelement 
restaurant est done public. 
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• La liste des occurrences de restaurants est geree sous l'element global 
restaurants issu du paquetage restaurants. 

• Par principe d'economie, le type de la classe restaurant nest pas publie en 
dehors de l'element restaurant. 

• L'element restaurant etant referencable, un attribut xsd:ID lui a ete automati- 
quement ajoute. 

• Lattribut nom de restaurant reference le type public nom. Le choix d'implementa- 
tion de PiloteWeb est d'avoir un attribut nom global. 

• Le type de donnees ho ran re etant un type compose, il donne lieu a un type com- 
plexe XML. 

• Le type de donnees heure correspond au type de donnees standard de XML 
schema : xs:time. 

• La classe restaurant a une association d'agregation avec la classe partenai re, ce 
qui donne lieu a un sous-element f i chePartenai re dont le type est enti tyRef . 

<xs: compl exType name="horai re"> 

<xs: attribute name="ouverture" type="xs :time"/> 

<xs: attribute name="fermeture" type="xs:time"/> 
</xs : compl exType> 

<xs:element name="restaurant"> 
<xs : compl exType> 
<xs:sequence> 

<xs: element name="horai re midi" type="pw: horai re"/> 
<xs: element name="horai re soi r" type="pw: horai re"/> 
<xs:element name="ficheRestaurant" type="pw:entityRef "/> 
</xs:sequence> 

<xs: attribute name="id" type="xs:ID"/> 
<xs: attribute ref="pw:nom"/> 
</xs : compl exType> 
</xs:element> 

<xs: element name="restaurants"> 
<xs : compl exType> 
<xs:sequence> 

<xs :element ref="pw: restaurant"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 
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Module de donnees « loueurs 



Figure 3-17 
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II existe des occurrences independantes et referencables de loueurs. L'element 

loueur est done public. 

La liste des occurrences de loueurs est geree sous l'element global 1 oueu rs issu du 

paquetage loueurs. 

Par principe d'economie, le type de la classe loueur n'est pas publie en dehors de 

l'element loueur. 

L'element loueur etant referencable, un attribut xsd:ID lui a ete automatique- 

ment ajoute. 

Lattribut nom de loueur reference le type public nom. Le choix d'implementation 

de PiloteWeb est d'avoir un attribut nom global. 

La classe loueur a une association d'agregation avec la classe partenai re, ce qui 

donne lieu a un sous-element f i chePartenai re dont le type est enti tyRef . 

<xs:element name="loueur"> 
<xs : compl exType> 
<xs:sequence> 

<xs:element name="ficheRestaurant" type="pw:entityRef "/> 
</xs:sequence> 

<xs: attribute name="id" type="xs:ID"/> 
<xs:attribute ref="pw:nom"/> 
</xs : compl exType> 
</xs:element> 

<xs:element name="loueurs"> 
<xs : compl exType> 
<xs:sequence> 

<xs:element ref="pw:loueur"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 
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Module de donnees « aeroclubs 



Figure 3-18 

Module de donnees 
« aeroclubs » 
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• II existe des occurrences independantes et referencables d'aeroclubs. L'element 
aerocl ub est done public. 

• La liste des occurrences d'aeroclubs est geree sous l'element global aerocl ubs issu 
du paquetage aerocl ubs. 

• Par principe d'economie, le type de la classe aerocl ub n'est pas publie en dehors 
de l'element aerocl ub. 

• L'element aerocl ub etant referencable, un attribut xsd : ID lui a ete automatique- 
ment ajoute. 

• Lattribut nom d'aeroclub reference le type public nom. Le choix d'implementation 
de PiloteWeb est d'avoir un attribut nom global. 

• La classe aerocl ub a une association d'agregation avec la classe partenaire, ce 
qui donne lieu a un sous-element f i chePartenai re dont le type est enti tyRef . 

<xs: element name="aeroclub"> 
<xs : compl exType> 
<xs:sequence> 

<xs:element name="ficheRestaurant" type="pw:entityRef "/> 
</xs:sequence> 

<xs: attribute name="id" type="xs:ID"/> 
<xs: attribute ref="pw:nom"/> 
</xs : compl exType> 
</xs:element> 

<xs: element name="aeroclubs"> 
<xs : compl exType> 
<xs:sequence> 

<xs: element ref="pw:aeroclub"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 
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Le schema relationnel de Implication PiloteWeb 

Comme nous l'avons indique au chapitre 2, le meme modele logique peut dormer 
lieu soit a un schema XML, soit a un schema relationnel. Sans entrer dans les details 
du modele relationnel, on peut observer a figure 3-19 les differences majeures avec 
les correspondances effectuees pour le schema XML. 

• Lorientation du graphe des associations n'est pas prise en compte. 

• Lorganisation des donnees en modules n'est pas prise en compte. 

• Les types de donnees complexes sont eux-memes transformes en liste de colonnes. 

Le modele relationnel est un modele global a plat, a partir duquel il est difficile 
d'operer par segmentation des donnees. Par exemple, la classe photo est promue au 
rang d'entite globale. Si une autre definition de photo apparait dans le schema, elle 
risque d'enter en collision avec celle donnee au titre de l'entite site. Dans le 
chapitre 4, nous aborderons plus en detail les differences entre le modele relationnel 
et le modele XML. 



ID aerodrome INTEGER 



localisationAerodrome INTEGER 



nom VARCHAR(25) 
code INTEGER 
frequence SMALLINT 



pilote 



ID_pilote 



iocolisationPiiote INTEGER 



nom VARCHAR(25) 
email CHAR(12) 
pwd CHAR(8) 



FK_aerodrome_site 



FK_pilote_site 



ID . site INTEGER 



photo INTEGER 



t 

FK_parten aire_site 



partenaire 



ID partenaire INTEGER 



localisationPartenaire INTEGER 



FK_site_photo 



photo 



ID photo INTEGER 



$> site_photographie INTEGER 



nomVARCHAR(25) 
format CHAR(4) 



~7f ? < 

FK_restaurant_partenaire FK_aeroclub_partenaire FK_loueur_partenaire 



ID_restaurant INTEGER 



fichePartenaire INTEGER 



nom VARCHAR(25) 
ouverture_midi TIME 
fermeture_midiTIME 
ouverture_soir TIME 
fermeture_soirTIME 



aeroclub 



ID aeroclub INTEGER 



fichePartenaire INTEGER 



Figure 3-19 Schema relationnel de PiloteWeb 



loueur 



IDJoueur INTEGER 



fichePartenaire INTEGER 



nom VARCHAR(25) 
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En resume... 



Les differentes etapes d'analyse du modele logique de donnees sont autant de 
moments indispensables au cadrage des modules qui constitueront le socle d'une 
architecture de donnees flexible et evolutive. L' analyse conjointe du regroupement 
des classes en paquetages et de l'orientation des associations permet de definir des 
regies de transformations des modeles UML vers le modele XML. Lobjectif n'est 
pas tant le developpement de filtres bi-directionnels de conversion d'un modele de 
donnees UML en schema XML, et vice versa, meme si, sur les cas simples, la con- 
version UML/XML reste possible. Identifier les classes concretes, leur reseau de 
relations et les possibilites de factorisation, les dependances qui en decoulent, void 
les objectifs principaux de l'analyse des modeles logiques. 



4 

Etape 4 - Specifier les 
modeles de stockage 



Un modele physique, ce n'est rien d'autre que la maniere dont les donnees sont phy- 
siquement stockees et identifiees. 

Les modeles physiques different en effet des modeles logiques car, a ce stade de la 
conception, il reste a definir precisement : 

• les lieux reels de stockage des documents XML et de leurs schemas associes ; 

• les relations entre elements qui dependent du stockage physique ; 

• les identificateurs d'elements qui peuvent egalement dependre du stockage 
physique ; 

• les noms des documents XML qui peuvent etre dependants du lieu de stockage 
physique. 

Ainsi, la representation physique des donnees n'est pas necessairement une projec- 
tion directe du modele logique. Par exemple, il peut etre utile, pour des raisons fonc- 
tionnelles de temps de reponse ou autre, de decouper le modele logique en plusieurs 
sous-schemas. II reste alors a creer ces nouveaux modeles et decider du lieu de stoc- 
kage des documents XML qui leur correspondent. 
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Avec les modeles physiques, nous allons done etre amenes a : 

• specifier l'eventuel decoupage du schema logique en sous-schemas, et introduire 
le cas echeant de nouveaux elements XML ; 

• specifier les URI correspondant aux espaces de noms des sous-schemas ; 

• specifier les lieux de stockage des sous-schemas et documents XML 
correspondants ; 

• adapter les liens en consequence. 

Ainsi, les modeles physiques representent la dispersion physique des donnees, tra- 
duisent des choix d'implementation et doivent permettre de garantir une exploitation 
optimale des donnees par les programmes. 

A cet effet, les representations UML suivantes pourront etre utiles : diagrammes de 
classes, diagrammes de composants et diagrammes de deploiement. 



Realiser un modele physique, demarche generate 

Pour definir le modele physique de stockage, nous adoptons une demarche de con- 
ception en trois temps, que nous presentons dans cette section. 

II faut commencer par identifier les questions generales : 

• Gestion d'un seul grand document XML ou de plusieurs petits ? 

• Gestion des revisions a l'interieur des documents XML ou par recopie des docu- 
ments XML ? 

• Stockage dans des fichiers, une base de donnees relationnelle ou une base de don- 
nees XML? 

Ces grandes lignes etant connues, il faut ensuite construire la strategic d'adressage 
des donnees : 

• Quels noms donner aux documents XML ? 

• Comment identifier les objets a l'interieur des documents XML ? 

• Quel langage de liaison mettre en oeuvre (XLink, XInclude, autres) ? 

• Les liens reposeront-ils sur des URL ? Des URI ? Des URN ? Des chemins 
d'acces physiques, logiques ? 

• Comment gerer les liens entre documents en base et documents hors base ? 

On terminera la conception en precisant quels elements serviront concretement de 
base aux liens en fonction des langages et modeles de liaison retenus : on choisira 
parmi les expressions XPointer, XPath, et requetes XQuery, selon le modele phy- 
sique etabli. 
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Definir la maniere dont les donnees seront 
physiquement stockees 

Choisir une forme de stockage 

A ce stade, nous n'avons aborde le probleme de la modelisation que sous le seul angle 
fonctionnel du systeme. Les relations entre les donnees avaient comme objectif 
d'exprimer la logique de l'application. Or, dans notre hypothese d'un systeme « tout 
XML », ces memes donnees doivent etre stockees dans des documents XML. C'est 
pourquoi nous allons aborder ici la question du modele de stockage a utiliser. 

Selon la facon de considerer le schema XML representant la vue logique, XML offre 
quatre possibilites : 

1 II est conserve en l'etat et les donnees sont entierement contenues dans un seul et 
meme document XML. 

2 II est conserve en l'etat mais les donnees donnent naissance a plusieurs documents 
XML du meme type. 

3 II est subdivise et les donnees sont reparties dans autant de documents XML qu'il 
y a de sous-schemas. 

4 II est subdivise et les donnees sont reparties dans plusieurs documents XML de 
meme type pour chacun des sous-schemas. 

Le tableau 4-1 resume ces quatre situations. 





Nombre de schemas 




1 


Plusieurs 


Nombre de 
documents 
XML par 
schema 


1 


La totalite des donnees de I'applica- II y a plusieurs schemas et un docu- 
tion est stockee dans un seul docu- ment XML de stockage des donnees 
mentXML. par schema. 


Plusieurs 


II n'y a qu'un seul schema, mais plu- II y a plusieurs schemas et, pour cha- 
sieurs documents XML de stockage cun, plusieurs documents XML de 
contiennent des donnees conformes stockage des donnees. 
a ce schema. 



A chaque cas correspondent des applications types que nous allons brievement 
decrire. 



Un seul schema et un seul document 

Dans ce cas, les donnees de l'application sont stockees dans un seul gros fichier 
XML. Cela n'est evidemment possible que si le volume de donnees reste acceptable 
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au regard des temps de reponse et si un seul schema XML suffit a satisfaire les 
besoins de l'application. Enfin, il faut savoir que, dans un tel cas, les mises a jour de 
la base ne pourront se faire que l'une apres l'autre. 

Des exemples : 

• les donnees echangees entre deux systemes informatiques ; 

• base contenant la totalite d'un manuel de maintenance d'avion. 
Quelques caracteristiques : 

• Le modele de stockage physique est egal au modele logique. 

• Le temps de montee du document en memoire (DOM) peut etre long, comme 
toutes les operations de manipulation du document. Le systeme de stockage doit 
pouvoir intervenir directement sur le DOM persistant. 

• Le systeme de stockage peut etre un simple fichier. 

• II n'y a pas de risque de conflit de noms de fichiers puisque, par definition, il n'y 
en a qu'un seul. Le nom du document XML qui contient les donnees peut etre 
determine et repere bien a l'avance. 

Un seul schema et plusieurs documents 

Dans ce cas, la totalite des donnees tient dans un seul type de document XML ; dans 
ce dernier toutefois, plusieurs documents sont necessaires pour contenir toutes les 
donnees. 

Des exemples : 

• Le cas typique est celui des documents XML figurant des documents papier. Le 
modele XML represente alors l'ensemble des documents (papier) d'un meme 
type, d'une meme famille. On aura par exemple un modele XML pour l'ensemble 
des modeles de lettres, un autre pour l'ensemble des modeles de fax, etc. II y aura 
autant de documents XML que de documents papier produits. 

• Un autre cas typique est celui de donnees qui representent par exemple des bons 
de commande : un seul schema XML correspond a n bons de commande. 

Quelques caracteristiques : 

• Les noms des documents XML produits devront forcement etre differents ; une 
forme lexicale generique de production de noms de fichiers ne peut etre decidee 
une fois pour toutes. 

• Ces ensembles de documents sont sensibles aux liens. Les noms des fichiers ne 
sont pas aises a modifier si des liens inter-documents existent. 
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Plusieurs schemas et un seul document par schema 

Ce cas est caracteristique des applications orientees donnees, comme PiloteWeb. Les 
documents XML trouvent alors tres bien leur place au sein d'une base de donnees 
XML. Les donnees sont reparties dans differents documents XML ayant chacun son 
propre schema. Chaque document XML contient la totalite des donnees d'un meme 
schema. 

Par exemple, dans PiloteWeb, le document XML pi 1 otes . xml contient la totalite 
des donnees specifiques aux pilotes, definies par le schema pi 1 ote . xsd. On aurait pu 
decider que chaque pilote disposerait de son propre fichier de donnees mais la con- 
ception a decide qu'elles seraient toutes reunies dans un seul et meme fichier. 



Figure 4-1 

Toutes les donnees de 
PiloteWeb tiennent dans 
9 documents XML de 
schemas differents. 



ll piloteWeb-data 

Q aeroclubs.xml 

^ aerodromes.xml 

Q loueurs.xml 

fi partenaires.xml 

^ pilotes.xml 

Q reperes.xml 

fi restaurants.xml 

Q sessions.xml 

^ sites.xml 



On en trouve des exemples typiques dans les applications de gestion de pieces de 
rechange, de commerce electronique, etc. 

Quelques caracteristiques : 

• Les noms des documents XML de stockage sont connus a l'avance. 

• lis peuvent etre contenus dans un meme repertoire. 

• Un tel modele fait penser aux tables de bases de donnees classiques : le role de 
chaque document XML peut etre assimile a celui d'une table. Toutefois, la struc- 
ture interne d'un document XML est a la fois infiniment plus riche et souple que 
celle d'une table. 

Plusieurs schemas et plusieurs documents par schema 

Dans ce cas, il faut plusieurs documents XML pour stocker les donnees d'un meme 
type. Cela se produit done quand on est oblige de dupliquer les documents XML 
d'un meme type : 

• soit parce qu'il y en a trop et que les documents XML seraient trop volumineux ; 

• soit parce qu'il serait inconcevable de garder toutes les donnees dans un seul docu- 
ment XML : e'est le cas des documents « papier » dematerialises. 
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Un exemple caracteristique est celui des documents « papier » decoupes en chapitres 
et/ou sections. Les chapitres et les sections sont tous d'un meme type, mais il est 
inconcevable de ne pas avoir un document XML par chapitre ou section. 

Afin que plusieurs documents XML d'un meme type puissent cohabiter dans un 
meme repertoire, le nom des fichiers les contenant doit obligatoirement varier d'un 
document XML a un autre. 

Quelques exemples : 

• Toute documentation qui est faite sur le principe de l'assemblage de modules 
structures. 

• Tout document XML contenant des donnees que Ton a prefere repartir dans plu- 
sieurs fichiers. Par exemple, on peut decider, pour gerer les villes francaises, 
d'avoir 26 documents XML d'un meme type : un par lettre de 1' alphabet. 

Quelques caracteristiques : 

• Les noms des fichiers contenant les documents XML peuvent ou non etre connus 
a l'avance ; quand ce n'est pas le cas, on definira une forme lexicale generique per- 
mettant de produire ces noms. 

• Tout lien doit obligatoirement tenir compte du nom precedent. En fonction de la 
strategic de gestion des revisions choisie, les liens devront egalement etre revises 
en cas de revision d'un document XML par copie. 

• La recherche d'une information devra balayer plusieurs documents XML. On 
pourra proceder a l'indexation des documents XML. 

Choisir une solution de stockage 

Comme nous l'avons rappele des l'introduction generate de cet ouvrage dans la sec- 
tion « XML au cceur des systemes d'information », l'une des specificites de XML est 
la diversite des possibilites de stockage : direct et en clair sous la forme de fichiers du 
systeme d'exploitation, eclate dans les tables d'une base de donnees relationnelle, ou 
encore sous la forme binaire et indexee d'une base de donnees XML. 

Dans les sections suivantes, nous presentons les grandes caracteristiques de ces diffe- 
rentes solutions de stockage. 

Stockage dans le systeme de fichiers 

La representation la plus commune des documents XML est le fichier. Le document 
XML est connu pour etre un fichier echangeable facilement. En effet, rien n'est plus 
facile que de stacker un fichier XML. 

La difficulte ne tient pas veritablement au stockage mais a ses consequences : 

• Quid des possibilites de recherche ? 
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• Quid des liens ? 

• Quid des possibilites de recoupement de donnees entre plusieurs documents XML ? 

En ce qui concerne le premier point, il est clair que les systemes d'exploitation 
actuels ne sont pas adaptes au stockage XML et ne fournissent aucune fonction par- 
ticuliere d'indexation et de recherche de l'information, et encore moins des services 
de requetes de type XQuery. 

En revanche, toutes les recommandations et normes derivees de XML font exclusi- 
vement appel aux URI et URL comme mecanismes standards d'adressage. Une con- 
sequence immediate est que les documents XML peuvent etre stockes a n'importe 
quel point d'un reseau accessible par une URL, a la maniere des pages HTML. 

Le stockage dans le systeme de fichiers est done tres simple, mais aussi tres pauvre. 
La recherche d'information est lente et il n'existe pas d'autre solution que de charger 
les documents XML en memoire : sans possibilite de requeter sur les documents 
XML ainsi stockes, l'affichage meme d'un mot necessite de charger la totalite du 
document XML en memoire ou d'utiliser des programmes de filtrage. Les systemes 
de fichiers sont egalement tres faibles en gestion des autorisations d'acces, controle 
des revisions et securite des transactions. 

Stockage dans une base de donnees relationnelle 

Le stockage des documents XML dans les bases de donnees relationnelles n'est pos- 
sible que dans un seul cas de figure : lorsqu'il n'y a qu'un seul schema et que les tables 
contiennent toutes les donnees d'un meme type. Cela revient a dire que n tables 
representent un schema et que les documents valides par rapport a ce schema sont 
eclates dans ces n tables. Pour qu'un modele relationnel represente plusieurs 
schemas, il faudra obligatoirement donner un prefixe aux elements de chaque schema 
(sinon, les elements de meme nom seront confondus). 

Le schema XML de stockage doit etre coherent avec ce type de stockage. Par 
exemple, il ne doit contenir aucun modele mixte. Cela fait une contrainte supple- 
mentaire forte a ajouter a celles deja relevees au tout debut de ce chapitre. 

Avec le modele relationnel, la dispersion des donnees dans differentes bases n'est plus 
possible : quand les elements sont repartis dans des tables, le concept meme d'URL 
disparait ; les liens ecrits avec Xpointer et XPath n'ont plus de sens direct. Sinon 
impossible, leur trouver une correspondance est dans le meilleur des cas couteux en 
temps de traitement. Dans le cas d'ecole expose dans ce chapitre, nous verrons com- 
ment Oracle XML DB resout cette question : les documents XML sont simultane- 
ment stockes sous forme d'une hierarchie de fichiers et eclates dans des tables con- 
formement aux principes theoriques que nous avons declines. 



Etapes de la demarche de modelisation 

Premiere partie 

Pour mettre en correspondance les modeles XML et relationnel, deux manieres 
d'aborder le probleme peuvent etre mises en oeuvre. L'une vise a rendre les mondes 
XML et relationnels interchangeables tandis que l'autre tend a les rendre uniformes : 

• On peut stacker un document XML independamment de son schema. Le 
modele relationnel est alors la simple reproduction de la forme des documents 
XML : des elements emboites les uns dans les autres sans typage particulier. On 
peut stocker dans une seule base physique des documents XML ayant des sche- 
mas differents. 

• Ou bien on stocke le document XML selon un modele relationnel adapte a sa 
DTD ou son schema XML. La cohabitation de documents XML issus de diffe- 
rentes DTD ou schemas XML n'est plus possible, de meme que 1'utilisation 
d'elements de meme nom qui sont de types differents. La seule maniere de con- 
tourner cette difficulte est d'utiliser l'artifice qui consiste a prefixer les noms des 
tables et des colonnes par le nom de leur modele. 

Linteret du stockage des donnees XML dans une base de donnees relationnelle est 
pourtant reel pour les entreprises : 

• reutilisation d'un systeme deja existant et eprouve ; 

• base installee importante ; 

• disponibilite de la competence ; 

• qualite eprouvee dans les domaines de la gestion des transactions et la securite. 

Cependant, le modele XML organise les informations sous forme d'arbre tandis que 
le modele relationnel les organise dans des tables. II n'y a done pas de correspondance 
directe entre ces deux modeles et, par consequent, passer d'un modele a l'autre 
requiert une certaine vigilance : tout n'est pas possible. Linformation du modele rela- 
tionnel doit etre organisee de maniere a refleter la nature hierarchique de XML. 

D'autres problemes persistent quand on veut stocker des documents XML dans du 
relationnel : 

• Qu'arrive-t-il quand on veut gerer les donnees en revision ? Dans ce cas, les rela- 
tions pere-fils deviennent dependantes du numero de revision et un element 
(done potentiellement une table) peut appartenir a plusieurs revisions et avoir 
plusieurs numeros d'ordre... 

• Aucun des modeles relationnels possibles ne permet d'offrir autant de degre de 
liberte de navigation dans les documents stockes que le modele XML. Les cibles 
XLink et XPointer n'ont aucune correspondance. 

• Le stockage des modeles mixtes n'est pas possible. 

• Lusage des espaces de noms pourrait compliquer davantage le stockage dans les 
tables. 
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Nous pensons que la mise en correspondance de donnees XML avec des modeles 
relationnels est fondamentalement reductrice et n'a d'interet que dans un seul cas : 
lorsqu'il faut fondre les donnees XML recues dans des donnees relationnelles, et ce 
sachant que Ton ne devra jamais ressortir ces donnees sous une forme identique au 
fichier XML utilise pour l'import, ni avoir un systeme ouvert a n'importe quel 
schema XML ou DTD. 

II est exclu de stocker des documents XML representant des documents (qu'il 
s'agisse de documents papier ou de pages HTML) dans des systemes relationnels. II 
est egalement illusoire de tenter de stocker dans des tables les documents XML car il 
faudrait gerer des revisions au niveau des noeuds ; il est enfin vain de penser con- 
server les possibilites de navigation dans les donnees et de lancement de requetes 
qu'offre XML : la puissance de XQuery ne se retrouve pas dans SQL ni dans une 
quelconque adaptation de XQuery au relationnel. 

Dans cette section, nous allons expliquer les trois methodes de transposition XML- 
Relationnel disponibles : 

• projection d'un document bien forme ; 

• projection d'une DTD ; 

• projection d'un schema XML. 

Le premier cas consiste a elaborer un modele relationnel generique capable de rece- 
voir n'importe quel document XML. Dans le deuxieme cas, il s'agit de construire le 
modele relationnel a partir de la lecture fidele d'une DTD, et, dans le dernier cas, on 
elabore le modele a partir d'un schema XML. 

II faut avant tout se detacher de l'aspect textuel d'un document. Apres tout, un docu- 
ment XML n'est qu'une maniere parmi n de serialiser l'information qu'il contient. 
Pour aborder le probleme de la transposition en relationnel, nous allons devoir nous 
interesser a ce que represente reellement le modele XML, a savoir des objets relatifs : 

• aux donnees : elements, espaces de noms, attributs et caracteres ; 

• aux documents eux-memes : le prologue, les instructions de traitement, les com- 
mentaires, les definitions de notations et d'entites. 

Dans le cadre de cette section, seuls les objets de la premiere categorie nous interes- 
sent. Dans la realite, il faudrait verifier que la base de donnees envisagee supporte 
effectivement les autres objets. 

Construction de structures arborescentes dans le modele relationnel 

Pour stocker un arbre dans un systeme de gestion de donnees relationnelles, on rea- 
lise une mise en correspondance, ou mapping, entre les informations de l'arbre et le 
schema de la base de donnees. Une pratique repandue consiste a creer une table par 
nceud, ou element, de l'arbre. Les relations de parente entre les elements sont alors 
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representees par des cles : une cle pour l'element parent, une reference a cette cle (cle 
etrangere) pour chaque element enfant. 



Figure 4-2 

Representation la plus 
generique d'un document XML 
sous forme relationnelle 




Dans l'exemple de la figure 4-2, l'element nl a deux enfants n2 et n3. Nous allons 
utiliser deux tables, Tab! e 1 pour l'element nl et Tab! e 2 pour les elements n2 et n3. 
II est important de remarquer que ces tables contiennent deux types d'informations : 

• celles propres a l'element ; 

• celles propres a la structure. 

Celles propres a l'element ont ete placees dans une colonne intitulee Informations 
auxili aires. II s'agit de ses attributs, de son contenu textuel et potentiellement 
d'informations complementaires comme son type. 

Celles propres a la structure ont ete reparties de la maniere suivante : 

• dans les colonnes ID de Tabl e 1 et Tab! e 2 qui contiennent une cle par element ; 

• dans la colonne PARENT_ID de Tabl e 2 qui reference le pere de chaque element de 
la table Tabl e 2 ; 

• dans la colonne INDEX qui permet d'ordonner les enfants des noeuds de la table 
Table 1. 

La figure 4-3 fournit la representation en UML de ce modele tandis que la 
figure 4-4 represents les tables correspondantes. 



Figure 4-3 

Diagramme logique 
du modele generique 
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Figure 4-4 

Tables relationnelles de 
notre modele generique 
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Une representation plus conceptuelle de ce modele montrerait explicitement la rela- 
tion parent-enfant. Pour cela, l'attribut migrant PARENT-ID deviendrait un role dans 
une association et l'attribut i ndex, qui sert a gerer l'ordre d'apparition des elements, 
deviendrait la caracteristique ordonne telle quelle apparait a la figure 4-5. 



VOCABULAIRE Attribut migrant 

Un attribut est qualifie de migrant pour indiquer qu'il represents une information atomique deja presente 
dans une autre table. En particulier, il est interessant de mettre en avant de tels attributs quand une rela- 
tion particuliere unit les deux informations. 



Figure 4-5 

Diagramme conceptuel du 
modele generique 



Table 


^iarent * 


Table 


+lnfci[TTiations airxiliaires 
+ID 


+l nf orma tions_aLKil iaires 




1 {Ordonne} 





II n'existe pas une facon unique d'assurer le stockage d'un document XML dans un 
systeme de gestion de donnees relationnelles. Par exemple, on peut choisir de 
regrouper les informations d'un element et ses attributs dans une seule table ou, au 
contraire, de les repartir sur plusieurs tables. Parmi toutes les possibilites, on dis- 
tingue deux cas extremes : 

• La totalite du document XML est ramene a une seule unite d'information ; typi- 
quement, le document textuel est stocke dans une colonne d'une table. 

• Chaque element du document XML est stocke dans une table independante et 
des index permettent de reconstruire le document. 

Le choix de l'un ou 1' autre cas de figure a des consequences importantes : 

• Sur les performances : dans le premier cas, retrouver le document est extreme- 
ment facile puisqu'une seule requete est necessaire. Dans le second cas en revan- 
che, l'information du document etant eclatee sur un grand nombre de tables, le 
nombre de requetes necessaires a la reconstitution du document va etre tres 
important. 

• Sur la recherche de documents ou de fragments de documents selon des criteres 
specifiques : le premier cas est tres pauvre et ne permet de faire des recherches que 
par mots-cles ou par reconnaissance de motifs textuels ; au contraire, le second 
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cas permet de faire des recherches bien plus riches puisque chaque element peut 
etre trouve directement. La base de donnees peut alors creer des index des noms 
et valeurs des elements, attributs et identificateurs uniques. 

La figure 4-6 a pour objectif de montrer que l'alternative entre un stockage condense 
et un stockage reparti est un choix antinomique. 



Figure 4-6 

Le paradoxe du stockage rela- 
tionnel de documents XML 



Document 
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Dans les sections suivantes, nous allons presenter plus en detail les possibilites de 
modelisation qui s'offrent pour definir des schemas relationnels adaptes au stockage 
de documents XML. Cette presentation n'est pas exhaustive, car il y a, comme nous 
l'avons dit, plusieurs facons de proceder. Les choix que nous avons faits se fondent 
sur plusieurs criteres : 

• La maniere dont l'information est repartie dans le schema relationnel. 

• La technique utilisee pour stocker les informations relatives a la structure arbores- 
cente. 

• Les donnees ajoutees au schema relationnel pour conserver l'information conte- 
nue dans le document XML. 

Chaque approche sera analysee de la meme maniere : apres avoir expose le modele, 
nous en presenterons les forces et faiblesses. 

L'approche Document Object Model (DOM) 

Cette approche utilise la representation d'un document sous sa forme DOM : le 
document XML va etre reproduit dans la base de donnees par une extraction des 
informations realisee grace aux API de DOM, qui definissent comment acceder aux 
informations d'un contenu dans un document XML. Dans ce cas, c'est la structure 
definie par DOM qui construit le schema relationnel. 

Si on ne considere que les unites d'information Document, Element, Attrlbut et Text, 
la representation UML du schema relationnel est representee par la figure 4-7. 

Lors de l'insertion d'un document XML dans la base de donnees, il faut tout d'abord 
en obtenir la vue DOM qui servira a inserer les informations relatives aux noeuds 



Etape 4 - Specifier les modeles de stockage 

Chapitre 4 



Figure 4-7 

Representation UMLdu schema 
relationnel dans le cas de 
I'approche DOM 
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dans les bonnes tables. Chaque element est decrit par deux tables et tous ont en 
commun la table Node (voir figure 4-7) qui contient les informations relatives aux 
relations parents-enfants de la structure ; c'est done elle qui porte la structure d'arbre 
du document. 

• L'attribut PARENT_ID est une cle etrangere de cette table qui pointe sur elle-meme. 

• L'attribut NODE_TYPE identifie le type du noeud et designe done implicitement la 
table ou se trouve le reste de l'information appartenant a ce nceud. 

• L'attribut NODE_INDEX est la position du noeud par rapport a sa fratrie. Cette table 
permet de conserver l'ordre initial des elements du document. 

Cette approche presente les points forts suivants : 

• Son aspect generique. Le modele nest lie a aucun document XML en particulier 
et permet de mettre dans la base n'importe quel document XML. 

• Simplicite de mise en ceuvre, apres construction du DOM, chaque element est 
stocke au moyen d'un simple parcours de l'arbre. 

• Le modele de contenu mixte est pris en compte par le systeme puisque dans 
DOM tout contenu textuel fait l'objet d'un noeud identifiable au meme titre 
qu'un sous-element. 
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En voici toutefois les points faibles : 

• L'utilisation de l'interface SAX nest pas possible ; il faut construire le modele 
DOM du document en memoire avant de l'inserer. C'est done penalisant en ter- 
mes de vitesse de traitement et d'occupation memoire. 

• Le document etant entierement reparti dans le schema relationnel, le nombre de 
requetes necessaires pour manipuler un document est proportionnel au nombre de 
noeuds concernes. En particulier, l'insertion d'un element necessite deux requetes 
pour l'element lui-meme et deux requetes pour chacun de ses attributs, ce qui est 
tres penalisant en termes de performances. 

L'approche DTD 

Cette approche se base sur le fait que le modele de contenu defini par une DTD 
permet de connaitre a l'avance les attributs portes par les elements. Par consequent, il 
est possible d'associer a chaque element une table stockant non seulement l'element 
mais encore ses attributs. En general, le nom de la table est le nom de l'element, mais 
pas obligatoirement. Les attributs forment les colonnes de la table. Ainsi, chaque 
element defini dans la DTD est associe a une table du modele relationnel. Outre les 
colonnes reservees aux attributs, on va trouver dans chaque table deux champs : l'un 
va servir de cle et 1' autre de cle etrangere indiquant l'element pere (a 1' exception de la 
table associee a l'element racine de la DTD). C'est le modele logique qui structure le 
schema relationnel. 

Nous allons fournir un exemple de cette approche a partir d'un cas concret. 

Supposons la DTD suivante : 

<!ELEMENT bi b~l iotheque (ouvrage*)> 
<!ATTLIST bib! iotheque nom #PCDATA #IMPLIED> 
<! ELEMENT ouvrage (auteur+)> 
<!ATTLIST ouvrage titre #PCDATA #IMPLIED> 
<! ELEMENT auteur (#PCDATA)> 

et son instance valide : 

<bib"l iotheque nom=""> 

<ouvrage titre="" annee=""> 
<auteur>. . .</auteur> 

<auteur>. . .</auteur> 
</ouvrage> 



Etape 4 - Specifier les modeles de stockage 

Chapitre 4 



<ouvrage titre= > 

<auteur>. . .</auteur> 



<auteur>. . 
</ouvrage> 
</bib~liotheque> 



, </auteur> 



Le schema relationnel est construit a partir de la DTD. La premiere version de ce 
schema est construite en utilisant des cles naturelles qui sont tout simplement les 
valeurs des noms des elements, comme le montre le diagramme UML de la figure 4-8. 

Dans l'approche DTD, il hy a pas, a proprement parler, de mecanisme d'insertion des 
documents. La seule fonction assuree par l'interface est la lecture des donnees conte- 
nues dans le document XML et leur recopie dans les bonnes tables. Une utilisation 
typique des donnees ainsi stockees est leur exploitation pour affichage via des requetes 
SQL sans aucune tentative de reconstruction d'un quelconque document XML (et 
encore moins un document XML egal a celui ayant servi a renseigner la base). 



Figure 4-8 

Diagramme UML du schema 
relationnel utilisant des cles 
naturelles dans l'approche DTD 
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La seconde version utilise, quant a elle, des cles artificielles qui seront generees par le 
systeme de persistance lors de l'insertion du document. 



Definition Cle artificielle 

Contrairement aux cles naturelles, les cles artificielles ne possedent pas de semantique particuliere. Elles 
sont souvent utilisees dans les cas suivants : 

• Quand aucun champ de la relation n'apparait comme bon candidat pour etre une cle, ce qui est le cas 
dans notre exemple. 

• Pour eviter d'avoir des cles etrangeres sur plusieurs colonnes, souvent compliquees a gerer. 

• Quand I'identifiant d'une relation est susceptible de changer, il est alors preferable d'utiliser une cle 
artificielle. Ainsi, les contraintes d'integrite ne changeront pas lors de changements d'attributs de la 
relation. 

Generalement, les cles artificielles sont produites par un generateur qui en garantit I'unicite. Les syste- 
mes de gestion de bases de donnees modernes fournissent generalement une fonction de generation de 
tel les cles. 
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Ce second schema est represente a la figure 4-9. 



Figure 4-9 

Diagramme UML du schema 
relationnel utilisant des des 
artificielles dans I'approche 
DTD 
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Les points forts de cette approche sont les suivants : 

• La modelisation est intuitive puisqu'elle suit le modele logique defini au depart 
dans la DTD. Le modele logique est une evidence et apparait a la premiere lec- 
ture du schema relationnel. 

• II est aise d'ecrire des requetes : c'est pratiquement les memes requetes que Ton 
ecrirait directement sur le modele relationnel. 

• Linsertion de donnees necessite un nombre de requetes moindre que dans 
I'approche DOM. Dans ce cas, l'insertion d'un element ne requerra qu'une 
requete et il en resultera done de meilleures performances. 

• Cette approche est tres peu intrusive ; les donnees necessaires pour conserver la 
structure d'arbre sont faibles ou inexistantes. 

Neanmoins, voici ses points faibles : 

• Chaque modele relationnel est specialise pour un type de document particulier et 
doit done etre ecrit specialement pour une DTD. Des outils toutefois permettent 
d'automatiser ce processus. 

• Lordre des elements est perdu. II reste possible de definir un attribut supplemen- 
taire de table pour ordonner les resultats obtenus lors des requetes selon l'ordre 
initial du document. Avec I'approche DTD cependant, si Ton souhaite transfor- 
mer des donnees XML entrantes en pures donnees SQL, l'ordre initial n'importe 
pas quand les donnees sont exploitees par des requetes globales qui portent sur 
l'ensemble des donnees. 

• Ce modele ne marche pas pour les elements qui ont un contenu mixte. 

L'approche XML Schema 

Lutilisation des schemas XML pour produire une correspondance entre un docu- 
ment XML et un systeme de gestion de donnees relationnelles differe assez nette- 
ment de celle d'une DTD. Tout d'abord, une DTD est basee sur la definition d'ele- 
ments, chaque element etablissant son modele de contenu et ses attributs, alors qu'un 
schema introduit la notion de type et est ainsi susceptible de casser completement la 
relation biunivoque qui existait dans les DTD entre un nom d'element et un modele 
de contenu. 
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Dans XML Schema, les types peuvent etre simples ou complexes. 

Les types simples sont utilises pour contraindre un element ou un attribut a avoir un 
contenu textuel d'un type donne. Par exemple : 

<xs: element name="exemple" type="xs :integer"> 

signifie que le contenu textuel de 1' element exemple sera forcement un nombre et 
devra etre conforme a la forme lexicale definie pour le type i nteger dans le tome II 
de la recommandation XML Schema ; par exemple : 



<exempl e>157<exempl e> 



Les types complexes ne s'utilisent que sur des elements et permettent de leur 
adjoindre des attributs et d'avoir un modele de contenu comportant des elements, 
par exemple : 

<xs : compl exType name="mon_type"> 

<xs: element name="element_l" type="xs:string"/> 

<xs: element name="element_2" type="xs:integer"/> 

<xs: attribute name="att_l" type="xs:integer"/> 
</xs : compl exType> 
<element name="exemple" type="mon_type"/> 

Ce modele signifie que le contenu de I'element exemple est compose d'un attribut 
att_l, lui-meme de type integer, et de deux sous-elements, element_l et 
element_2, respectivement de type string et integer. 

Les schemas XML Schema empruntent plusieurs notions a la programmation 
orientee objet, comme l'heritage et la notion de type abstrait, dont voici un exemple : 

<xs : compl exType name="mon_type"> 

<xs: attribute name="attl" type="xs :string"/> 
</xs : compl exType> 

<xs : compl exType name="mon_type_heri te_l"> 
<compl exContent> 
<extension base="mon_type"> 

<xs: attribute name="att2" type="xs :integer"/> 
</extension> 
</compl exContent> 
</xs : compl exType> 

<xs : compl exType name="mon_type_heri te_2"> 
<compl exContent> 
<extension base="mon_type"> 
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<xs: attribute name="att3" type="xs :boolean"/> 
</extension> 
</compl exContent> 
</xs : compl exType> 



Dans un document, tout element possedant le type mon_type pourra utiliser 
n'importe quel type herite, c'est-a-dire mon_type_hen'te_l ou mon_type_hen'te_2. 

Les consequences de ces differences sont les suivantes : 

• Le fait que les schemas soient bases sur les types implique que le contenu et les 
attributs d'un element ne sont plus fixes (uniques), comme cela etait le cas avec 
une DTD. Selon le contexte, un element aura differents types. II n'est done plus 
possible de mettre directement en relation un element et une table predefinie du 
modele relationnel. 

• La notion d'heritage augmente la complexite : etant donne un document XML, 
on ne peut pas prevoir le type de certains de ses elements. Cela se produit 
lorsqu'un element declare un type qui possede plusieurs types herites. Le type sera 
alors decouvert lors de l'analyse du contenu du document XML grace a l'attribut 
xsi :type qui permet a l'auteur du document de declarer pour un element le type 
qu'il a choisi, levant ainsi toute ambiguite. 

En conclusion de ce que nous venons de voir, nous pouvons retenir que 
XML Schema place de facto le probleme de mise en correspondance des donnees 
XML avec des tables relationnelles entre la premiere et la deuxieme des approches 
etudiees dans le debut de ce chapitre. 

XML Schema requiert toutefois que Ton regarde de plus pres ce qui se passe pour 
chaque cas d'unite d'information : les elements et leurs attributs, la structure, le con- 
tenu textuel. 

Les elements 

Avec XML Schema, le type d'un element peut fluctuer, y compris a l'interieur meme 
du document XML, quand on utilise le typage fiottant autorise avec l'attribut 
xsi :type. Les formes possibles d'un ensemble d'information rattache a un schema 
XML peuvent considerablement varier, contrairement aux DTD. Nous avons vu qu'il 
n'est pas possible d'assigner un element a une table finie comme dans l'approche DTD. 
Cette derniere approche fonctionne car le nombre de colonnes, qui depend du nombre 
d'attributs, est connu a l'avance, et parce que ce nombre est fixe. Cependant, dans le cas 
des schemas, ce nombre varie avec la possibilite de donner, a la volee, un type a un ele- 
ment. Cet heritage dynamique de type est illustre par les figures 4-10 et 4-11. 

La solution que nous allons developper fait reposer la mise en correspondance du 
XML avec le relationnel sur la base des types et non plus des elements. Autrement 
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Figure 4-10 

La relation biunivoque 
entre elements et tables 
de I'approche DTD 
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Figure 4-11 

La relation entre elements 
et tables des modeles 
par type (XML Schema) 
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dit, chaque element d'un document XML sera stocke dans une table correspondant a 
son type et non plus a son nom d'element. 

Nous presentons tout d'abord la persistance de la structure arborescente et montrons 
que, sur ce point, les deux methodes vues precedemment peuvent etre utilisees. 
Ensuite, nous verrons comment prendre en compte les elements textuels de maniere 
efficace. 

La structure arborescente 

Les figures 4-12 et 4-13 decrivent les modeles relationnels qu'il convient d'appliquer 
selon que Ton souhaite suivre une approche DOM ou une approche DTD. 

Si l'option DOM est choisie (figure 4-12), la table el ement decrit la structure hierar- 
chique du document : 

• ID : ce champ contient la cle primaire de l'element. 

• TABLE : ce champ contient le nom de la table dans laquelle I'element est stocke. 

• N0DE_INDEX : ce champ sert a retenir l'ordre des fils d'un element. 
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Figure 4-12 

Diagramme UMLde la 
methode DOM appliquee a 
I'approche XML Schema 
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PARENT_ID : ce champ, cle etrangere sur le champ ID de cette meme table, donne 
pour un element la cle de son pere. 
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Diagramme UMLde la 
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Si l'option DTD est retenue (figure 4-13), les relations parent-enfant sont distri- 
buees sur les tables contenant les elements. 

La comparaison entre les deux modeles obtenus apporte les conclusions suivantes : 

• Pour un element donne, trouver l'ensemble de ses enfants est simple avec I'appro- 
che DOM et complique avec I'approche DTD. En effet, avec cette derniere, il 
faut iterer la recherche sur toutes les tables contenant des fils potentiels et rassem- 
bler tous les resultats. Cela a bien evidemment un cout en termes de performances 
tandis qu'avec I'approche DOM, le nombre de requetes necessaires sera reduit au 
strict minimum. 

• Obtenir le pere d'un element donne : cette operation est similaire dans les deux cas. 
On voit done qu'il est preferable de choisir I'approche DOM. 



Lorsqu'un element est stocke dans la table correspondant a son type, il faut conserver le nom que I'ele- 
ment porte dans le document XML. On peut proceder de deux facons differentes. Soit on adjoint un champ 
dans la table el ement (figure 4-1 2) dans lequel on viendra stacker le nom de I'element, soit on ajoute ce 
champ sur chaque table (Type 1, Type n . . ., des figures 4-1 2 et 4-1 3) qui represents un type. 
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Les elements textuels 

Le stockage des elements textuels est effectue dans une table speciale qui contient les 
contenus de tous les elements textuels du document : 



Figure 4-14 

Table de stockage 
des donnees textuelles 



Text 



DATA 



Le stockage du texte mixte necessite un traitement specifique. 

Stockage dans une base de donnees XML 

En comparaison des problemes que pose la projection du modele relationnel, le prin- 
cipe du stockage du XML dans une base native XML est simple. 

On qualifie de native une base de donnees dont la gestion des index repose sur le 
principe des arbres et des relations parents-enfants. II existe une algebre de parcours 
des arbres XML, tout comme il existe une algebre du modele relationnel. Ainsi, les 
documents XML ne sont pas transformes au moment de leur stockage : on ne 
cherche pas a faire rentrer une roue dans un carre et il n'y a par consequent aucune 
distorsion. 

Les noeuds de l'arbre correspondant a un document XML peuvent etre identifies par 
des uplets (i , j). 

Dans le tableau 4-2, nous representons un fragment simple ainsi que les valeurs i,j, 
correspondant aux elements ou noeuds. Le calcul est simple : le document XML est 
represente sous sa forme normale ASCII et, au fur et a mesure de sa lecture, un 
compteur est incremente par pas de 1 a chaque fois qu'un nouvel element ouvrant ou 
fermant est rencontre. 



1 


X 

J 


<pi"loteWeb xmlns:xsi="http: //www. w3.org/2001/XMLSchema-instance" 
xsi : noNamespaceSchemaLocati on="schemaLogi queDePi 1 oteWeb . xsd"> 


1 




<sites> 


2 




<site unique-id="pl"> 


3 




<nom>pi"lote l</nom> 


4 


5 


<position x="3" y="3"/> 


6 


7 


<photo nom="http : //www. pi 1 oteWeb . com/pl . gi f " f ormat="gi f "/> 


8 


9 
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1 J 


</site> 




10 


<s"ite unique-id="p2"> 


11 




<nom>pilote 2</nom> 


12 


13 


<position x="3" y="4"/> 


14 


15 


<photo nom="http://www. piloteWeb.com/p2 .png" format="png"/> 


16 


17 


</site> 




18 


</sites> 




19 


</piloteWeb> 




20 



Si Ton represente ce fragment sous forme d'arbre, on obtient la representation de la 
figure 4-15. 



Figure 4-15 

Indexation des elements d'un 
document XML 



piloteWeb Q 



1,20 




16,17 



position photo nom position photo 



Les operations simples de navigation entre noeuds peuvent des lors etre calculees de 
la facon suivante : 

• Le noeud frere d'un noeud de coordonnees (i , j) est forcement le noeud de coor- 
donnees (j+l,k). 

• Le premier enfant d'un noeud de coordonnees (i , j) est le noeud de coordonnees 
(i+l,k). 

• Etc. 

D'autres approches existent, mais notre objectif nest pas dans cet ouvrage de les 
detailler toutes. 



Etape 4 - Specifier les modeles de stockage 

Chapitre 4 



Une base de donnees XML se presente comme une arborescence de repertoires et de 
fichiers mais, a la difference du simple systeme de fichiers, elle offre des fonctions 
avancees d'indexation, requetes, gestion des droits d'acces et controle des transactions. 

Une base de donnees XML presente les caracteristiques suivantes : 

• Les documents XML peuvent y etre stockes meme si le schema ou la DTD qui 
les accompagnent est inconnu(e). Grace aux algorithmes d'indexation et a la 
forme normalisee du XML, de nombreuses operations de traitement (principale- 
ment, le requetage et les modifications) sont possibles. 

• Plusieurs documents XML peuvent cohabiter meme si leurs schemas (ou DTD) 
sont differents. 

• La gestion des revisions est prise en charge et le stockage des seules differences 
entre deux versions d'un meme document permet d'optimiser la taille de la base. 

• II est aise d'exporter tout ou partie de la base et de copier-coller tout ou partie 
d'un document XML entre la base et une autre application. 

Ces types de systeme de gestion de bases de donnees combinent done la commodite 
du systeme de fichiers avec les possibilites d'indexation et de controle des mises a jour. 

La figure 4-16 montre une base de donnees XML. 



Ml X-Hive/DE Administrator - nhive://localhost:1235 



JnJjlJ 



Database Settings/ Federation Help 



_J united nations 
€>- _| Segments 

I Groups 
©■ CjI Users 
9 li root-library 
©- _cj Catalog 

0- I Documents 

©■ J DemoXQuery 

9 _i pilote Web-data 
Q aoroclubs.xml 
Q aerodromes.wrnl 
Q loueurs.xml 
Q partenaires.xml 
Q pilotes.xml 
Q reperes.xrnl 
Q re stau rants. xml 
Q sessions xml 
Q site sjrnll 
J XLink 
J scrternas 



Connected as Administrator j | 



Properties [ Indexes Y Text I 
Text search: 



Search 



< ?xiul v e l h i un= " 1 . " enuudiny = "UTF- S " . ? > 

<sites: sites xttLns:xsi='*http: //www. w3.org/ 2 001/XHL Schema- instance" 
xsi: sche*aLocation= rr www.piloteVeb.xml/sites sites. xsd" 
xalns: sites= rr wwu.pilote¥eb.xml/sites rr > 
<site3:site unique -iii= ,r il rr > 
<no«>Pilote de Dem<K/nom> 
<photo nom="pingouin. jpg" Eormat="ipg rr /> 
<position> 

<x>48.7494C/x> 
<Y>-2.1108</y> 
</position> 
</sites: site> 

<site3:site unique -id="i 2 "> 
<noM>Nicolas le Panda</nom> 
<ptaoto nom="Merlin.gif " f ooiat= rr gif ,r /> 
<.po3ltlon> 

<x>47.9505</x> 
<5>-0.19</5> 
</position> 
</sites: site> 



a 



Figure 4-16 Dans une base de donnees XML, on navigue 
dans les donnees XML comme on parcourt un systeme de fichiers. 
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Toutes les operations possibles sur les bases de donnees classiques le sont egalement 
avec une base de donnees XML, y compris les jointures de documents XML qui 
s'expriment, en XQuery, de la maniere suivante : 

for $i in document("/P"NoteWeb-data")//nom, 

$j in document("/Documents")//nomNorm 
where $i = $j 
return <res>{$i }</res> 

Ici, la clause for permet de construire deux listes d'objets dont on demande ensuite le 
recoupement au moyen d'une clause where. 

En resume, le choix d'un stockage du XML dans une base relationnelle ou une base 
XML ne peut se discuter que : 

• Par rapport a l'entropie que genere le stockage du XML dans le relationnel (le mot 
entropie represente ici l'energie qu'il faut developper pour que cela marche - tenant 
compte des degradations fonctionnelles que le relationnel apporte au XML). 

• Par la necessaire compatibilite avec d'autres applications : il se pourrait que les 
donnees XML ne fassent que representer une partie des donnees d'une application 
plus vaste. Dans ce cas, c'est cette derniere qui decidera du mode de stockage. 



Construire la strategic d'adressage 



Une fois le type de stockage defini, il faut aborder la question du mode d'adressage 
des donnees. XML offre plusieurs possibilites, toutes tres precises : 

• Le referencement par des identifiants uniques de type ID/IDREF : le probleme, 
c'est que XML limite la portee de ce mecanisme aux liens intra-documents. Luti- 
lisation des ID/IDREF ne marche qua l'interieur d'un seul et meme document 
XML. II ne peut done en aucun cas etre utilise pour repertorier (referencer) des 
donnees se trouvant dans plusieurs documents XML. 

• Les URL permettent de cibler des elements precis, d'un document XML precis, 
se trouvant sur une machine precise. Si les URL sont choisies, cela signifie que le 
stockage a l'interieur de la base de donnees reproduit le systeme des fichiers : 
seule une base de donnees XML permet de le faire. 

• Les URI necessitent qu'un catalogue de correspondance entre des adresses physi- 
ques et logiques soit operationnel. 

• Les liens simples XLink : votre systeme de stockage doit appliquer cette recom- 
mandation, comme c'est generalement le cas. 
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• Les liens complexes XLink : contrairement aux liens simples, les liens XLink de 
type complexe sont rarement pris en charge. 

• Les liens d'inclusion XInclude. 

• Les expressions XPath qui permettent de definir un element cible relativement a 
d'autres, voire de calculer une trajectoire. XPath reste un langage declaratif dont 
les capacites de calcul sont limitees. 

• Les requetes XQuery reprennent le principe des expressions XPath en les enrobant 
d'un langage procedural. C'est un langage puissant qui permet d'adresser et creer 
artificiellement des liens entre des donnees qui n'auraient pas ete initialement 
modelisees pour (des elements porteurs d'aucun identifiant particulier par exemple). 

A ce stade de la conception, vous devez faire la distinction entre : 

• les identifiants, liens et references qui devront etre poses manuellement par des 
auteurs des documents XML ; 

• les identifiants, liens et references qui pourront etre poses par des programmes ; 

• les liens qui seront le fruit d'un calcul fait a la volee, en general au moment de 
I'affichage des donnees. 

Dans le cas ou l'information serait posee manuellement, la question est toujours de 
savoir si l'utilisateur dispose de l'information pour poser son lien. Question qui se 
decline ainsi : peut-il voir la cible ? Doit-il en connaitre (et comment) les identifiants 
internes ? Peut-il poser son lien par une operation de copier-coller ? Etc. 

Dans le cas du lien calcule par programme, la question posee est toujours celle de la 
mise a jour du lien quand l'information ciblee evolue : le lien est-il stable dans le 
temps ? Comment le mettre eventuellement a jour ? 



Cas d'ecole : PiloteWeb 

Dans cette section, nous presentons ce que serait le stockage des donnees de Pilote- 
Web dans chacun des trois cas de figure : le systeme de fichiers, des tables relation- 
nelles, et enfin la base de donnees XML. 

Decoupage initial du modele logique 

Au chapitre 3, nous avions obtenu le modele logique des donnees de PiloteWeb, avec 
une mise en evidence de la structure logique que nous representons a nouveau ci- 
apres a la figure 4-17. 
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Figure 4-17 
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L'analyse fonctionnelle de l'application fait apparaitre que les mises a jour des don- 
nees de la base sont assurees par plusieurs personnes, travaillant de maniere syn- 
chrone sur la base : 

• Les aeroclubs vont inscrire de nouveaux pilotes. 

• Les autorites de regulation de la circulation aerienne vont declarer de nouveaux 
aerodromes ou modifier les caracteristiques des aerodromes et aeroclubs existants. 

• Les services des chambres de commerce regionales vont prendre en charge l'ins- 
cription des partenaires des aerodromes et aeroclubs. 

Si nous conservons toutes les donnees dans un seul document XML, tel que notre 
modele logique l'impose dans son etat actuel, ces utilisateurs ne pourraient modifier 
les donnees qu'en procedant l'un apres l'autre. 

Pour reduire les temps d'acces a la base, nous allons done decider de decouper la 
structure physique en plusieurs parties, chacune pouvant etre mise a jour indepen- 
damment des autres. 

Pour cela, nous allons transformer chacun des elements enfants de l'element pi 1 oteWeb 
en element racine d'un document XML. Notre base sera ainsi composee de huit docu- 
ments XML, correspondant a huit schemas differents. Nous optons done pour un 
choix de base de type n , 1 : n schemas et un seul document XML par schema. 
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La figure 4-18 donne la representation du schema du document XML qui con- 
tiendra les donnees relatives aux pilotes (element pi Tote). Un nouvel element 
pilotes (avec un s) a ete introduit pour servir de racine a ce document XML. 



Figure 4-18 

Representation en UML du 
schema correspondant au stoc- 
kage physique des donnees 
relatives aux pilotes 
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Ci-apres, nous presentons huit extraits des documents XML que nous allons obtenir 
suite a ce decoupage. 



Remarque anyURL 

Le type anyURL n'existe pas dans la recommandation XMLSchema. Le type le plus proche que nous 
puissions utiliser est anyURI; ce que nous avons fait ici. 



Un document XML pour les sites 

<?xml version="1.0" encoding="UTF-8"?> 

<sites xm"lns:xsi ="..." xsi :noNamespaceSchemaLocation="sites.xsd"> 
<site unique-id="pl"> 
<nom>Nicolas le Panda</nom> 
position x="48.7494" y="-2 . 1108"/> 

<photo nom="http://www.piloteWeb. com/pl.gif" format="gif"/> 
</site> 
</sites> 
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Un document XML pour les pilotes 

<?xml version="1.0" encoding="UTF-8"?> 
<pilotes> 
<pi"lote unique-id="idll" pub"lie="l idrefSite="pl"> 
<emai 1 >pi 1 ote@pi 1 oteWeb . com</emai 1 > 
<pwd>avi on</pwd> 
</pi"lote> 
</pi"lotes> 

Un document XML pour les aerodromes 

<?xml version="1.0" encoding="UTF-8"?> 
<aerodromes> 
<aerodrome unique-id="idl3" idrefS"ite="al"> 
<f requence>125 . 90</f requence> 
<code>LFRM</code> 
</aerodrome> 
</aerodromes> 

Un document XML pour les partenaires 

<?xml version="1.0" encoding="UTF-8"?> 
<partena"i res> 
<partenai re unique-id="idpal5" idrefSite="pal"> 
<adresse>ZI des Arbihres Saint-Nazai re </adresse> 
<tel ephone>+33 . 2 . 35 . 60 . 42 . 89</tel ephone> 
</partenai re> 
</partenai res> 

Un document XML pour les reperes 

<?xml version="1.0" encoding="UTF-8"?> 

<reperes> 
<repere unique-id="id23" idrefSite="rl"/> 
<repere unique-id="id24" idrefSite="r2"/> 

</reperes> 

Un document XML pour les aeroclubs 

<?xml version="1.0" encoding="UTF-8"?> 

<aeroc"lubs> 
<aeroc"lub unique-id="idl7" idrefPart="idpal5"/> 
<aeroc"lub unique-id="idl8" idrefPart="idpal6"/> 

</aeroc"lubs> 
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Un document XML pour les restaurants 

<?xml version="1.0" encoding="UTF-8"?> 
<restaurants> 
<restaurant unique-id=""idl9" idrefPart="idrel5"> 
<horai res>Des 7 heures et jusqu'a 20h. tous les jours sauf le WE 
</horai res> 
</restaurant> 
</restaurants> 

Un document XML pour les loueurs 

<?xml version="1.0" encoding="UTF-8"?> 
<loueurs> 

<loueur unique-id="id21" idrefPart="idlol5"/> 

<loueur unique-id="id22" idrefPart="idlol6"/> 
</~loueurs> 

Remarque : nous avons remplace par ... l'URI de XML Schema, a savoir 
http://www.w3.org/2001/XMLSchema-instance, et ce par souci d'economie de place. 

Or, comme les donnees sont decoupees dans plusieurs documents XML indepen- 
dants, le mecanisme des ID/IDREF initialement mis en place pour partager les don- 
nees entre elles ne fonctionne plus. Par exemple, le fait d'ecrire <restaurant 
unique-id="idl9" idrefPart="idrel5"> ne suffit plus pour savoir ou se trouve la 
donnee referencee puisqu'il manque desormais l'indication du fichier de la cible de 
cette reference. En l'etat actuel, seule la programmation des chemins d'acces en dur 
dans les programmes de 1' application permettrait de resoudre ce point. 



Stockage dans un systeme de fichiers 

Nous allons prendre le cas simple ou tous les documents XML et leurs schemas asso- 
cies sont stockes dans un meme repertoire. 

A la figure 4-19, nous representons un repertoire dans lequel sont stockes indiffe- 
remment les schemas XML et les documents XML correspondants. 

A la maniere des documents HTML, nous utilisons dans ce cas des URL pour 
exprimer les liens entre les donnees, et ce afin d'eviter a l'application de devoir gerer 
cette partie de la logique du modele de donnees. 

II faut aussi prevoir un lieu de stockage pour les elements graphiques de 
l'application : les images qui correspondent a i'element photo doivent se trouver dans 
un repertoire connu de l'application. 
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Figure 4-19 
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Nous montrons ci-dessous ce que cela donnerait dans les documents de PiloteWeb. 

Pour garantir la qualite de l'environnement, il conviendra de modifier les schemas de 
ces documents XML pour y adapter tant les noms des attributs que leur type. 

Nous allons montrer dans les sections suivantes comment les schemas XML, logique 
et conceptuel, relatifs a l'element pi Totes s'en trouvent modifies. 

Un document XML pour les sites (Uni que-i d remplace par name) 

<?xml version="1.0" encoding="UTF-8"?> 

<sites xm"lns:xsi="..." xsi :noNamespaceSchemaLocation="sites.xsd"> 
<site name="pl"> 
<nom>Nicolas le Panda</nom> 
<position x="48.7494" y="-2 . 1108"/> 
<photo nom="photos/pl.gif" 
format="g"if"/> 
</site> 
</sites> 
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Un document XML pour les pilotes (IdrefSite remplace par href) 

<?xml version="1.0" encoding="UTF-8"?> 
<pilotes> 
<pi"lote name="idll" publie="l" href="sites.xml#pl"> 
<emai 1 >pi 1 oteOpi 1 oteWeb . com</emai 1 > 
<pwd>avi on</pwd> 
</pilote> 
</pi"lotes> 

Un document XML pour les aerodromes (Unique-id remplace par name, IdrefSite remplace 
par href) 

<?xml version="1.0" encoding="UTF-8"?> 
<aerodromes> 
<aerodrome name="idl3" href="sites .xml#al"> 
<f requence>125 .90</f requence> 
<code>LFRM</code> 
</aerodrome> 
</aerodromes> 

Un document XML pour les partenaires (Unique-id remplace par name, IdrefSite remplace 
par href) 

<?xm1 version="1.0" encoding="UTF-8"?> 
<partenai res> 
<partenaire name="idpal5" href="sites.xml#pal"> 
<adresse>ZI des Arbihres Saint-Nazai re</adresse> 
<tel ephone>+33 . 2 . 35 . 60 . 42 . 89 
</telephone> 
</partenai re> 
</partenai res> 

Un document XML pour les reperes (Unique-id remplace par name, IdrefSite remplace par 

href) 

<?xml version="1.0" encoding="UTF-8"?> 
<reperes> 

<repere name="id23" href="sites .xml#rl"/> 

<repere name="id24" href=" sites. xml#r2"/> 
</reperes> 
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Un document XML pour les aeroclubs (Unique-id remplace par name, IdrefSite remplace par 
href) 

<?xml version="1.0" encoding="UTF-8"?> 

<aeroc"lubs> 
<aeroc"lub name="idl7" href="partenai res.xml#idpal5"/> 
<aeroc"lub name="idl8" href="partenai res.xml#idpal6"/> 

</aeroc"lubs> 

Un document XML pour les restaurants (Unique-id remplace par name, IdrefSite remplace 
par href) 

<?xml version="1.0" encoding="UTF-8"?> 
<restaurants> 
<restaurant name="idl9" href="partenai res.xml#idrel5"> 
<horai res>Des 7 heures et jusqu'a 20h. tous les jours sauf le WE 
</horai res> 
</restaurant> 
</restaurants> 

Un document XML pour les loueurs (Unique-id remplace par name, IdrefSite remplace par 
href) 

<?xml version="1.0" encoding="UTF-8"?> 
<1oueurs> 

<1oueur name="id21" href="partenai res .xml#idlol5"/> 

<1oueur name="id22" href="partenai res .xml#idlol6"/> 
</loueurs> 



Stockage en relationnel 

Dans cette section, nous allons presenter la facon dont les modeles et documents de 
PiloteWeb ont pu etre stockes dans le produit Oracle XML DB. (Oracle 9iR2). 

Comme nous allons le voir, le contenu des documents XML est a la fois reparti dans 
des tables et sous la forme d'une arborescence de fichiers. Larborescence hierar- 
chique est constituee de noeuds, chacun d'eux pouvant etre un document XML ou un 
dossier. La repartition des documents est identique a celle utilisee pour le stockage 
dans un systeme de fichiers. Vous pouvez choisir l'arborescence et les lieux de stoc- 
kage des objets. 

L'acces a ce referentiel est obtenu par les protocoles HTTP, FTP, WebDAV, ce que 
represente la figure 4-20. 
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Figure 4-20 
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Avec ce produit, il faut distinguer : 

1 les vues qui permettent de representor une arborescence de fichiers a la maniere 
d'un systeme de fichiers ; 

2 les vues qui representent les structures XML internes des documents stockes. 

Vues representant I'arborescence des fichiers 

De par sa capacite a representer et gerer les documents et schemas XML sous la 
forme d'une arborescence de fichiers, Oracle XML DB se presente comme un sys- 
teme de stockage hierarchique de document XML. On peut acceder a ces documents 
en utilisant les protocoles HTTP, FTP ou WebDAV, ou encore en utilisant l'un des 
langages de requetes SQL, PLSQL ou Java. 

Pour stocker les schemas dans la base, la premiere operation consiste a charger les 
fichiers contenant les schemas XML dans l'un des repertoires virtuels deja crees dans 
la base. En effet, Oracle XML DB permet de creer de tels repertoires. Nous mon- 
trons ci-apres un exemple de scripts de creation de tels repertoires : 

set echo on 
connect &1/&20&3 

declare 

result boolean; 
begin 

result := dbms_xdb.createFolder('/home/' || USER || '/xsd'); 
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result := dbms_xdb.createFolder('/home/' || USER 
result := dbms_xdb.createFolder('/home/' || USER 

result := dbms_xdb.createFolder('/home/' || USER || 

end; 

/ 

COMMIT; 



I VxsT); 

I '/PiloteWeb'); 

'/photos'); 



Ce script donne une arborescence que Ton peut consulter a partir d'un navigateur 
Web (resultat illustre par la figure 4-21). 



Figure 4-21 
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C'est dans le repertoire /home/JJT/xsd que seront stockes les schemas XML. On 
peut y proceder au moyen d'un telechargement via FTP. 

Les figures 4-22, 4-23 et 4-24 montrent les differentes etapes de ce telechargement, 
soit respectivement : 

• la connexion a la base ; 

• la selection d'un repertoire de destination ; 

• le depot des schemas. 
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Figure 4-22 Connexion a Oracle XML DB 
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Figure 4-23 Selection du repertoire virtuel de destination 
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Figure 4-24 Depot des schemas dans le repertoire virtuel de destination 
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Oracle XML DB charge les informations des fichiers deposes dans deux vues 
principales : 

• La vue RESOURCE_VIEW : elle contient une ligne par ressource enregistree dans la 
base. 

• La vue PATH_VIEW : elle contient les chemins d'acces aux ressources stockees dans 
la base. 

La figure 4-25 represente ces deux vues. 



Les vues resource et SI' "" '•" ,.„ T ,„ 

path de Oracle XML DB 



RES 






SYS. XMLTYPE 


ANY PATH 






VARCHAR2I 4 0) 


S QL > des c 


at h 


i ew 




Name 






Hul 1 Type 



VARCHAR2I 1024) 
SYS. XMLTYPE 
SYS. XMLTYPE 



La figure 4-26 montre la requete SQL a executer pour avoir la liste des chemins 
d'acces aux ressources stockees dans la base, tandis que la figure 4-27 montre la 
requete fournissant, pour Fun des schemas stockes, les informations detaillees le con- 
cernant, et qui se trouvent dans la table resource_view. 

Figure 4-26 aSSES^^^^^^^^^^^^^^^^^mt^^^mm joi*i 



Requete SQL montrant 
les schemas identifies 
dans la table resource view 



select any_pat h from resourcevi ew where anypath like ' / h o me / 1 J T / x s d / %' 



/ ho me /J J T/ xsd/ aerocl ubs. xsd 
/ home/J J T/ xsd/aerodromes. xsd 

/home/JJT/xsd/loueurs.xsd 

/ home/J J T/ xsd/ part enai r es. xsd 

/home/JJT/xsd/pilotes.xsd 

/ home/ J J T/ xsd/ reperes . xsd 

/ home/J J T/ xsd/ restaurants, xsd 

/ home/J J T/ xsd/ si tes. xsd 

8 r ows sel ec t ed. 



Comme nous l'avons deja fait, il est possible, via HTTP, d'interroger directement la 
base en utilisant simplement FURL http://i2949:8080/home/JJT/xsd, comme le montre 
la figure 4-28. 
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Figure 4-27 

Requete permettant d'obtenir 
les informations de gestion 
pour I'un des schemas stockes 



1* select res from resource 
SQL > / 

RES 



where AN¥_ PATH = ' / home/ J j T/ xsd/ s i t es . x s d ' 



- P x| 
-I 



<Resour ce> 

<Cr e a t i on Dat e>2004- 12- 2 8T0 7: 49: 53. 743000000 </ Cr ea t i onDate> 

<Modi f i cati onDat e>2004- 12- 28T07: 49: 53. 743 000000 </ Modi f i cati on Da t e > 

<Di spl ay N a me > s i t es. wsd</ Di spl ay Name > 

<Language>en</ Language> 
<Character5et>utf - 8</Character5et > 
<ContentType>text/pl ai n</ContentType> 
<Ref Count >1</Ref Count > 
</ Resour ce> 



SQL> 



Figure 4-28 

Requete HTTP fournissant 
les donnees de gestion 
des schemas 
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En cliquant sur l'un des noms de schemas, le contenu s'affiche dans le navigateur 
aussi simplement que s'il s'agissait d'un fichier stocke dans un repertoire du systeme 
d'exploitation. Dans la figure 4-29, vous voyez le resultat apres avoir clique sur 
aeroclubs.xsd. 

Dans cette vue, vous pouvez immediatement remarquer l'utilisation de l'attribut 
xdb:defau"ltTable="AEROCLUBS", dont la presence montre que le schema XML a du 
etre adapte avant son chargement dans la base. Ce point sera etudie dans la pro- 
chaine section. 

La derniere vue possible est celle obtenue via WebDAV, dans laquelle les repertoires 
virtuels de la base apparaissent comme autant de repertoires du systeme d'exploita- 
tion (figure 4-30). 
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Figure 4-29 
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Figure 4-30 
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Vues relatives aux schemas 

Dans cette section, nous allons voir comment Oracle XML DB gere la structure des 
schemas XML que nous lui avons demande de stocker. 

En observant la figure 4-29, il apparait que deux informations ont ete ajoutees dans 
le schema XML : 

• une declaration d'espace de noms, a savoir : 
xml ns : xdb="http : //xml ns . oracl e . com/xdb" ; 

• un attribut specifiant un nom de table, a savoir xdb : def aul tTabl e="AEROCLUBS". 

De telles informations ainsi que les scripts presentes dans cette section vont per- 
mettre de prendre en compte la structure des schemas XML : 

• generation de la structure en fonction du schema XML ; 

• creation des tables, vues et colonnes XMLTYPE a partir de schemas XML enre- 
gistres. 

On pourra ensuite effectuer le stockage automatique des documents dans les tables 
qui correspondent a un ou plusieurs schema(s) XML enregistre(s). 

Pour que la structure definie par le schema soit enregistree dans la base, il faut 
demander au systeme de le faire. Nous montrons ci-apres les commandes utilisees a 
cet effet. 

Set echo on 
connect &1/&20&3 

alter session Set events=' 31098 trace name context forever' ; 

begin 

dbms_xml schema. regi sterSchema( 

' http : //I2949 : 8080/J JT/si tes . xsd ' , 

xdbURITy pe ( ' /nome/II JT/xsd/si tes . xsd ' ) . getCI ob O , 

TRUE, TRUE, FALSE, TRUE); 
dbms_xml schema. regi sterSchema( 

' http : //I2949 : 8080/home/]:T/xsd/aerocl ubs . xsd ' , 

xdbURIType( ' /home/D JT/xsd/aerocl ubs . xsd ' ) . getCI ob() , 

TRUE, TRUE, FALSE, TRUE); 
dbms_xml schema. regi sterSchema( 

' http : //I2949 : 8080/home/]:T/xsd/aerodromes . xsd ' , 

xdbURITy pe( ' /home/] JT/xsd/ae rod romes . xsd ' ) . getCI ob() , 

TRUE, TRUE, FALSE, TRUE); 
dbms_xml schema. regi sterSchema( 

' http : //I2949 : 8080/home/]JT/xsd/l oueu rs . xsd ' , 

xdbURITypeC/home/DJT/xsd/loueurs.xsd') .getCTob() , 

TRUE, TRUE, FALSE, TRUE); 
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dbms_xml schema. regi sterSchema( 

' http : //I2949 : 8080/home/j JT/xsd/partenai res . xsd ' , 

xdbURITypeC/home/j 1 JT/xsd/partenai res .xsd') . getClob() , 

TRUE, TRUE, FALSE, TRUE); 
dbms_xml schema. regi sterSchema( 

' http : //I2949 : 8080/home/ D jT/xsd/pi 1 otes . xsd ' , 

xdbURITypeC /home/D JT/xsd/pi "I otes. xsd' ).getC"lob(), 

TRUE, TRUE, FALSE, TRUE); 
dbms_xml schema. regi sterSchema( 

' http : //I2949 : 8080/home/j jT/xsd/reperes . xsd ' , 

xdbURITypeC /home/D JT/xsd/reperes. xsd') . getClob() , 

TRUE, TRUE, FALSE, TRUE); 
dbms_xml schema. regi sterSchema( 

' http : //I2949 : 8080/home/j JT/xsd/restaurants . xsd ' , 

xdbURITy pe(' /home/ 1 JT/xsd/ restaurants .xsd') . getClobO , 

TRUE, TRUE, FALSE, TRUE); 
End; 
/ 

A la figure 4-31, nous montrons la liste des tables resultant de cette operation 
d'enregistrement. 



Figure 4-31 

Liste des tables generees a 
partir des schemas XML du 
referentiel 
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TABLE i 








OBJECT_NAME 








OBJECT 


_TVPE 


AERO CLUBS 








TABLE 




AERODROMES 








TABLE 




LCJEJRS 








TABLE 




PARTENAIRES 








TABLE 




PILOTE 








TABLE 




PILOTES 








TABLE 




RE PERES 








TABLE 




RE ST AU RANTS 








TABLE 




SITES 








TABLE 




ae ro dr oni el 42 _T AB 








TABLE 




partenaire453_TAB 








TABLE 




site«1_TAB 








TABLE 




12 rows selected. 
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Nous allons analyser la decomposition d'un schema XML en table. Pour illustrer 
cette analyse, nous allons utiliser les tables pi 1 otes et pi 1 ote issues du schema XML 
pi Totes. xsd. A cet effet, nous avons du apporter quelques modifications au schema 
XML des pilotes. 

Elles sont mises en valeur a la figure 4-32. 
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Figure 4-32 

Le schema pilotes.xsd soumis a 
Oracle XML DB 



<?xml versiDn= ,l 1.0" encoding="i5n-3S59-l" ?> 

< xs: schema xmlns:xs="http:// www.w3.org/2 001/XML5che ma" 

|xmlns:xdb="http://xm lns.oraclg.com/xdb"! version = "1.0" > 

- <xs:complexType name= J 'piloteType" |xcib'5QLType="XDBPI_TYPE il >] 

- <xs:sequence> 

- <xs:element name= ,L link"> 
- <xs:complexType> 

<X5:anyAttribute 
na mespacE="http:/ / www.w3.org / 1999/xlinlc" 
p rac es s Co ntents= "strict" /> 
</xs: complexType> 
</xs:element> 

<xs:element name="email" type="emain"vpe" nillable="false" 
rxdF:SQLName="MAIL"7> | 

< xs:element name="pwd" ty pe="xs:HCName" nillable= "false" 
rxdb:SQLName="PWD" />] 
</xs:sequence> 

<xs:attribute name= "unique- id" type= xs:ID" /> 
<xs: attribute name="publie" type="xs:integer" defaijlt="l" /> 
</xs; complexType> 

- <xs:simpleType name="emailTyp©"> 

- <xs: restriction base = "xs:stiing"> 

<xs: pattern value="(\c)*@(\c)*" /> 

</xs: restrictions 
</xs:simpleType> 
<xs:element name="pilote" type="piloteType" 

lxdb:defaultTable="PILOiTT/> 

- <xs: element name="pilotes" |%db^defaultTable="FILQTES">l 

- <xs:complexType> 

- <xs:seq jence> 

<xs:element ref="pilote'' maxOccurs="unbounded " /> 
</xs:sequence> 
</xs:complexType> 
</xs:element> 



1 



SQL> set long 1000 

SQL> set wrap ON 

SQL> set linesize 200 

SQL> desc pi Totes 

TABLE of SYS.XMLTYPE(XMLSchema "http://I2949:8080/home/]JT/xsd/pilotes .xsd" 

Element "pilotes") STORAGE Object-relational TYPE "pilotes457_T" 

SQL> 

SQL> desc "pilotes457_T" 

"pilotes457_T" is NOT FINAL 

Void le resultat de cette requete : 



Name 


Type 


SYS_XDBPD$ 


XDB.XDB$RAW_LIST_T 


Pi 1 ote 


pilote458_C0LL 
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Dans notre schema, l'element pi Totes contient un seul element, pilote, defini globa- 
lement par un type complexe nomme ; ce dernier fait l'objet d'une table particuliere 
(la table pi~lote458_COLL). Nous en demandons la structure via la requete suivante : 

SQL> desc "pilote458_C0LL" 

"pi"lote458_C0LL" VARRAY(2147483647) OF XDBPI_TYPE 

"pilote458_COLL" is NOT FINAL 

Void le resultat de cette requete : 



Name Type 


SYS_XDBPD$ XDB.XDB$RAW_LIST_T 


unique-id 


VARCHAR2(4000) 


Publie 


NUMBER(38) 


Link 


Link455_T 


MAIL 


VARCHAR2(4000) 


PWD 


VARCHAR2(4000) 



La table du type piloteType (pilote458_C0LL) stocke directement dans ses 
colonnes les objets de type simple, qu'il s'agisse des attributs (unique-id, Publie) ou 
des sous-elements (MAIL, PWD) du type. On remarquera que les elements email et pwd 
ont ete stockes sous les noms MAIL et PWD puisque cela a ete explicitement demande 
dans le schema (voir encadres de la figure 4-32). 

Le sous-element link, qui est de type complexe, fait l'objet d'une table separee. 
Nous en demandons la structure via la requete suivante : 

SQL> desc "link455_T" 
"link455_T" is NOT FINAL 

Void le resultat de cette requete : 



Name Type 


SYS_XDBPD$ 


XDB.XDB$RAW_LIST_T 


SYS_XDBANYATTR456$ 


VARCHAR2(4000) 



Du fait du type generique (anyAttribute) qui sert a definir l'element link, 
Oracle XML DB decide de creer un seul long champ. 

L'element pi 1 ote pointe vers la table de son type. Quand on demande sa structure, 
on obtient une description deja rencontree plus haut : 
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SQL> desc pi Tote 

TABLE of SYS.XMLTYPE(XMLSchema "http://I2949:8080/home/]JT/xsd/pilotes .xsd" 

Element "pilote") STORAGE Object-relational TYPE "XDBPI_TYPE" 

Et le resultat de cette requete est le suivant : 



SQL> desc XDB.XDB$RAW_LIST_T 
XDB.XDB$RAW_LIST_T VARRAY(IOOO) OF RAW(2000) 



Name Type 


SYS_XDBPD$ XDB.XDB$RAW_LIST_T 


unique_id VARCHAR2(4000) 


Publie 


NUMBER(38) 


Link 


Link455_T 


MAIL 


VARCHAR2(4000) 


PWD 


VARCHAR2(4000) 



Finalement, la figure 4-33 represente la structure des tables creees par Oracle XML DB. 



Figure 4-33 

Representation des tables 
creees par Oracle pour le 
schema pilotes.xsd 
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umquejti. van c h an'J(4 u uu ) 

publie : N UM BE R (38) 

link lir*45S T 

mail . VAR CHAR 2(4000) 

pwd :VAR CHAR 2(4000) 



Table pilote 



Type XDBPITYPE 



Type linM55_T 



L>"v •jji.iMiru$ :xu u .x du$k aw_li y i _ r 
SYS_XDBAN YA TTR45 6$ VARCH AR 2(40 DO ) 
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La recuperation des fichiers XML 

Pour recuperer les fichiers, on peut egalement proceder de plusieurs manieres : au 
moyen de FTP ou WebDAV. 

Pour illustrer cette phase, nous allons verifier le resultat de la recuperation, avec le 
fichier XML pilotes.xml, charge dans le repertoire /home/JJT/PiloteWeb 
(figure 4-34). 



Figure 4-34 
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Cependant, avant de charger le fichier XML dans la base de donnees, il faut changer 
son en-tete pour y indiquer le chemin d'acces au schema correspondant dans Oracle 
(repere ©). 

<pi 1 otes xml ns : xl i nk=http : //www . w3 . org/1999/xl ink 
xml ns : xsi =http : //www. w3 . org/2001/XMLSchema-i nstance 
xsi : noNamespaceSchemaLocati on="http : //I2949 : 8080/home/J JT/xsd/ 
pilotes.xsd"> <- © 

Apres le chargement du fichier, on peut verifier le contenu de la base Oracle en exe- 
cutant la requete SQL suivante : 

ISQL> select count(*) from PILOTES; 
1 



Oracle n'a stocke qu'une ligne au niveau de la table pi 1 otes, et cette ligne contient 
l'ensemble du fichier XML. 

On peut toutefois afficher la ligne de la table pi 1 otes dont un element email con- 
tient la valeur max@pi 1 oteweb . com. 
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SQL> select value (x) from pilotes x 

2 where existsNode(value(x) , '//pilote[email="max@piloteweb.com"] ') = 1; 

<pi 1 otes xml ns : xl i nk="http : //www . w3 . org/1999/xl i nk" 
xml ns : xsi ="http : //www . w3 . org/2001/XMLSchema-i nstance" 

xsi : noNamespaceSchemaLocati on="http : //I2949 : 8080/home/] ]T/xsd/pi 1 otes . xsd"> 
<pilote unique-id="il6" publie="l"> 

<!--link xlink:type="simple" xlink:show="embed" xlink:href= 

"sites. xml /#xpointer (descendant: : si te[@unique-id='il' ])"/--> 

<emai 1 >pi 1 ote@pi 1 oteweb . com</emai 1 > 

<pwd>avi on</pwd> 
</pilote> 
<pilote unique-id="il7" publie="l"> 

<!--link xlink:type="simple" xlink:show="embed" xlink:href= 

"sites. xml /#xpointer (descendant: : si te[@unique-id='i2 '])"/--> 

<emai 1 >panda@pi 1 oteweb . com</emai 1 > 

<pwd>secret</pwd> 
</pilote> 
<pilote unique-id="il8" publie="l"> 

<! --1 ink xlink:type="simple" xlink:show="embed" xlink:href= 

"sites. xml /#xpointer (descendant: : si te[@unique-id='i 3' ])"/--> 

<emai 1 >max@pi 1 oteweb . com</emai 1 > 

<pwd>secret</pwd> 
</pilote> 

<pilote unique-id="il9" publie="l"> 
<! --1 ink xlink:type="simple" xlink:show="embed" xlink:href= 

"sites. xml /#xpointer (descendant: : si te[@unique-id='i 4' ])"/--> 
<emai 1 >snai 1 @pi 1 oteweb . com</emai 1 > 
<pwd>secret</pwd> 
</pilote> 
</pilotes> 

La requete SQL a trouve dans la table un element correspondant au critere de 
recherche. Comme la table ne contient qu'une ligne, cette requete ramene la ligne 
complete, et done le contenu du fichier XML. 

En revanche, si on utilise la requete suivante, on obtient en retour le seul element 
emai 1 requis : 

SQL> select x.extract('//pilote/email ') from pilotes x where 
existsNode(value(x) , ' //pi lote [emai l="max@pil oteweb. com"] ') = 1; 
<emai 1 >max@pi 1 oteweb . com</emai 1 > 

Pour obtenir ce resultat, e'est la fonction specifique x . ext ract qui a ete utilisee au 
lieu du standard select. 
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La mise a jour d'un fichier XML 

II est possible d'utiliser des chemins XPath dans des requetes SQL de mise a jour. En 
voici un exemple : 

SQL> update pilotes p 

2 set value(p) = 

3 updateXml (value (p) , ' //pi Tote [3] /email /text () ' , 'maxi@piloteweb.com') 

4 where existsNode(value(p) , 

5 '//pilote[position()= 3 and email="max@pi loteweb.com"] ') = 1 

6 / 

Cette requete met a jour la chaine de caracteres de 1' element email pointe par 
l'expression XPath (repere O) : 

1 row updated. 

SQL> select xdbURIType('/home/' || USER 

|| '/PiloteWeb/pilotes.xml ') .getXMLO from dual ; 

<pi 1 otes xml ns : xl i nk="http : //www . w3 . org/1999/xl i nk" 
xml ns : xsi ="http : //www . w3 . org/2001/XMLSchema-i nstance" 

xsi : noNamespaceSchemaLocati on="http : //I2949 : 8080/home/J ]T/xsd/pi 1 otes . xsd"> 
<pilote unique-id="il6" publie="l"> 

<! --1 ink xlink:type="simple" xlink:show="embed" xlink:href= 

"sites. xml /#xpointer (descendant: : si te[@unique-id='il' ])"/--> 

<emai 1 >pi 1 ote@pi 1 oteweb . com</emai 1 > 

<pwd>avi on</pwd> 
</pilote> 
<pilote unique-id="il7" publie="l"> 

<! --1 ink xlink:type="simple" xlink:show="embed" xlink:href= 

"sites. xml /#xpointer (descendant: : si te[@unique-id='i2 '])"/--> 

<emai 1 >panda@pi 1 oteweb . com</emai 1 > 

<pwd>secret</pwd> 
</pilote> 
<pilote unique-id="il8" publie="l"> 

<! --1 ink xlink:type="simple" xlink:show="embed" xlink:href= 

"sites. xml /#xpointer (descendant: : si te[@unique-id='i 3' ])"/--> 

<email>maxi@pil oteweb. com</email> <- O 

<pwd>secret</pwd> 
</pilote> 

<pilote unique-id="il9" publie="l"> 
<! --1 ink xlink:type="simple" xlink:show="embed" xlink:href= 

"sites. xml /#xpointer (descendant: :site[@unique-id='i4 '])"/--> 
<emai 1 >snai 1 @pi 1 oteweb . com</emai 1 > 
<pwd>secret</pwd> 
</pilote> 
</pilotes> 
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Stockage dans une base de donnees XML 

Dans cette section, nous allons montrer comment les documents XML ont ete 
repartis et modifies a des fins de stockage dans une base de donnees XML. 

La repartition des documents est sensiblement identique a celle effectuee pour leur 
stockage dans un systeme de fichiers. La seule difference porte sur le lieu de stockage 
des schemas XML et des objets graphiques : 

• Concernant les schemas XML, ils sont stockes automatiquement dans une zone 
de la base reservee aux schemas. 

• Quant aux objets graphiques, nous choisissons de les stocker a l'exterieur de la 
base, dans l'un des sous-repertoires du serveur d'application que nous utilisons, a 
savoir jakarta-tomcat-4.0.1. On precede ainsi en raison de la grande simplicite 
de gestion de ces objets graphiques et de notre souci d'eviter des operations de 
stockage/destockage. 

La figure 4-16 montre le resultat du stockage des fichiers de PiloteWeb dans une 
base de donnees XML. 

La figure 4-35 presente le repertoire Img cree dans l'application PiloteWeb du ser- 
veur d'application jakarta-tomcat. 



Figure 4-35 
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On considere ici que les illustrations sont des objets du meme niveau que les feuilles 
de style de l'application. Elles sont stockees a l'exterieur de la base de donnees, mais 
toutefois dans une zone de l'application logique par rapport a son architecture. En 
clair, nous n'avons pas stocke ces donnees dans le premier repertoire utilisateur venu. 
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La encore, les references vont devoir etre changees : 

• S'agissant des ID/IDREF utilises entre les paquets XML dans le modele logique 
originel, nous allons devoir les remplacer par des liens reellement pris en charge 
par les mecanismes de la base de donnees : ce sera XLink dans notre cas. 

• S'agissant des illustrations, nous optons pour une reconstruction dynamique de 
leur URL d'adressage au moment de l'affichage. Nous nations done garder a 
l'interieur des donnees XML que le nom physique du fichier concerne. En effet, 
ayant assimile ces objets a des elements de l'application, il est logique que Identi- 
fication de leurs chemins d'acces soit prise en charge par l'application et non par 
les utilisateurs. II serait illogique que ce chemin soit grave en dur dans les donnees. 

Nous montrons ci-apres ce que deviennent les documents XML de PiloteWeb une 
fois adaptes aux considerations qui viennent d'etre exposees. 

Document XML pour les sites (dans I'attribut nom, nous ne precisons que le nom physique du 
fichier contenant I'objet graphique) 

<?xml version="1.0" encoding="UTF-8"?> 

<sites xm"lns:xsi ="..." xsi :noNamespaceSchemaLocation="sites.xsd"> 

<site unique-"i d="pl"> 

<nom>Nicolas le Panda</nom> 

<position x="48.7494" y="-2 . 1108"/> 

<photo nom="pl.gif" format="gif"/> 
</site> 
</sites> 

Document XML pour les pilotes (I'attribut i d ref Si te est remplace par un element link porteur 
des attributs XLink) 

<?xml version="1.0" encoding="UTF-8"?> 
<pilotes> 
<pilote unique-id="idll" publie="l"> 
<link xlink: type=" simple" xlink:show="embed" 
xlink:href="sites.xml/#xpointer( 

descendant: : site[@unique-id='pl'])"/> 
<emai 1 >pi 1 ote@pi 1 oteWeb . com</emai 1 > 
<pwd>avi on</pwd> 
</pilote> 
</pilotes> 
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Document XML pour les aerodromes (I'attribut i d ref Si te est remplace par un element link 
porteur des attributs XLink) 

<?xml version="1.0" encoding="UTF-8"?> 
<aerodromes> 
<aerodrome unique-id="idl3"> 
<link xlink:type="simple" xlink:show="embed" 
xlink:href="sites.xml/#xpointer( 

descendant: :site[@unique-id='al'])"/> 
<f requence>125 .90</f requence> 
<code>LFRM</code> 
</aerodrome> 
</aerodromes> 

Document XML pour les partenaires (I'attribut i dref Si te est remplace par un element link 
porteur des attributs XLink) 

<?xml version="1.0" encoding="UTF-8"?> 
<partenai res> 
<partenai re unique-id="idpal5"> 
<link xlink:type="simple" xlink:show="embed" 
x"link:href="sites.xm"l/#xpointer( 

descendant : : si te [@uni que-i d= ' pal ' ] ) "/> 
<adresse>ZI des Arbihres Saint-Nazai re 
</adresse> 

<tel ephone>+33 . 2 . 35 . 60 . 42 . 89</tel ephone> 
</partenai re> 
</partenai res> 

Document XML pour les reperes (I'attribut i d ref Si te est remplace par un element link porteur 
des attributs XLink) 

<?xml version="1.0" encoding="UTF-8"?> 
<reperes> 
-crepere unique-id="id23"> 
<link xlink:type="simple" xlink:show="embed" 
xl i nk : href ="si tes . xml /#xpoi nter ( 

descendant: : site [Ouni que-i d=' rl'])"/> 
</repere> 

<repere unique-id="id24"> 
<link xlink:type="simple" xlink:show="embed" 
xlink:href="sites .xml/#xpointer( 

descendant: : site [Ouni que-i d=' r2 '])"/> 
</repere> 
</reperes> 



Document XML pour les aeroclubs (I'attribut i d ref Si te est remplace par un element link porteur 
des attributs XLink) 

<?xml version="1.0" encoding="UTF-8"?> 
<aeroclubs> 
oeroclub unique-id="idl7"> 
<link xlink: type="simple" x"link:show="embed" 
xlink: href="partenai res .xml/#xpointer( 

descendant: :partenai re[@unique-id=' idpal5 '])"/> 
</aeroclub> 

<aeroclub unique-id="idl8"> 
<link xlink: type=" simple" xlink:show="embed" 
xlink:href="partenai res.xml/#xpointer( 

descendant: :partenai re[@unique-id=' idpal6'])"/> 
</aeroclub> 
</aeroclubs> 

Document XML pour les restaurants (I'attribut i dref Si te est remplace par un element link 
porteur des attributs XLink) 

<?xml version="1.0" encoding="UTF-8"?> 
<restaurants> 
<restaurant unique-id="idl9"> 
<link xlink: type="simple" xlink:show="embed" 
xlink:href="partenai res.xml/#xpointer( 

descendant: :partenai re[@unique-id=' idrel5 '])"/> 
<horai res>Des 7 heures et jusqu'a 20h. tous les jours sauf le WE 
</horai res> 
</restaurant> 
</restaurants> 

Document XML pour les loueurs (I'attribut id ref Site est remplace par un element link porteur 
des attributs XLink) 

<?xml version="1.0" encoding="UTF-8"?> 
<loueurs> 
<loueur unique-id="id21" 

href="partenai res .xml#idlol5"> 
<link xlink: type="simple" xlink:show="embed" 
xlink:href="partenai res.xml/#xpointer( 

descendant: :partenai re[@unique-id=' idlo5 '])"/> 
</loueur> 
<loueur unique-id="i32"> 
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<link x"link:type="simple" x"link:show="embed" 
xlink: href="partenai res .xml/#xpointer( 

descendant: :partenai re [@unique-id='id"lo6 '])"/> 
</loueur> 
</loueurs> 

L'introduction de XLink nous oblige a modifier les schemas physiques individuels ainsi 
que le modele logique des donnees. Tout depend de la capacite de l'outil de modelisa- 
tion a reconnaitre la semantique des liens de type XLink. S'il y parvient, le modele phy- 
sique pourra etre produit automatiquement : dans le cas contraire, on devra chaque fois 
en passer par une retouche manuelle pour regenerer les schemas XML physiques. 



En resume... 



Nous avons vu dans ce chapitre que XML laisse une grande liberte de choix dans la 
mise en oeuvre physique des modeles de donnees. Si ses avantages sont la souplesse, 
la flexibilite et l'adaptabilite, il n'en est pas moins vrai que les modeles physiques sont 
In fine differents des modeles logiques. 

La mise en oeuvre physique de XML entraine des modifications dans les modeles qui 
peuvent remonter jusqu'au modele conceptuel. II faut done prevoir une necessaire 
serie d'iterations entre les modeles conceptuels, logiques et physiques dans le deve- 
loppement d'applications basees sur XML. 

On retiendra que les facilites d'adressage dont est pourvu XML ont deux conse- 
quences majeures sur les modeles de stockage physique : 

• Ces derniers presentent des caracteristiques qui les differencient radicalement des 
modeles conceptuels : en partie grace a la puissance de XQuery qui permet, le cas 
echeant, de reconstruire a la volee un DOM conforme au modele conceptuel. 

• Le modele conceptuel peut etre divise en autant de sous-modeles independants 
que necessaire. Cela n'empeche pas les donnees d'etre liees entre elles. 
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Une fois le modele de stockage realise, on peut dire que le modele de donnees et sa 
transcription en XML sont maitrises. Un travail plus fin peut alors commencer. II a 
pour objet d'optimiser le schema XML. 

Dans ce chapitre, nous allons presenter le travail d'optimisation qui consiste a etu- 
dier, element par element et attribut par attribut, la qualite de la semantique trans- 
mise par ces objets aux applications. 

Nous allons repondre aux questions suivantes : 

• Quels noms definitifs donner aux elements et attributs ? 

• Comment faire passer plusieurs semantiques par element ? 

• Quel ratio etablir entre elements et attributs ? 

• Quelle est la semantique d'un attribut par rapport a celle d'un element ? 

• Comment choisir entre attribut et sous-element ? 
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Principes de base 

Par le passe, on confondait souvent le fait de savoir lire le XML et celui de savoir lire 
les donnees. II convient de revenir sur ce point pour le clarifier. 

Pour nous aider dans cette tache, nous allons considerer qu'un document XML pre- 
sente toujours trois niveaux de lecture : 

• Le niveau syntaxique : un programme comprenant la syntaxe XML sera toujours 
capable de lire un document XML, meme en n'en comprenant pas la semantique 
du balisage, et meme sans avoir besoin d'en connaitre le schema. Qui plus est, ce 
programme sera capable d'operer sur ce document lu « a l'aveugle » toute une 
serie d'operations de traitement, voire de transformation. Si les operations de 
chargement en memoire et de transformation sont parmi les plus importantes, il 
ne faut pas oublier pour autant la gestion des liens avec XLink, des inclusions 
avec Xinclude et de requetage avec XQuery Pour toutes ces operations, seule une 
lecture de niveau syntaxique suffit : elle correspond au niveau InfoSet, le modele 
de base des documents XML presente au chapitre 2. 

• Le niveau structurel : les programmes comprenant un schema XML peuvent dire 
si un document est structurellement valide, c'est-a-dire conforme a la structure 
hierarchique definie par le schema qui lui est associe. 

• Le niveau semantique : les programmes comprenant la semantique des objets 
XML savent leur appliquer des regies metier. Les donnees contenues dans le 
document XML peuvent des lors etre echangees intelligemment avec d'autres 
applications : on obtient un systeme d'information. 

Les frontieres qui existent entre ces niveaux doivent etre connues et analysees, du 
moins a ce stade de la conception. Cependant, l'existence de ces niveaux laisse l'ini- 
tiative aux developpeurs d'applications : ils peuvent construire progressivement leur 
architecture de donnees. 

Les elements et attributs XML sont pris entre deux feux : d'un cote, ils doivent servir 
a controler la qualite des donnees qu'ils contiennent et, de l'autre, ils doivent etre 
intelligemment relies aux traitements. En meme temps, un utilisateur doit pouvoir 
deviner quasi naturellement leur sens a la seule lecture. Quand un element s'appelle 
date, on se doute bien qu'il s'agit d'une date, mais un element de nom datelc (qui 
pourrait signifier date limite de commande) laisse reveur. 

Une partie de la flexibilite et de l'evolutivite demandees aux systemes d'information 
modernes se joue sur la lisibilite du XML qu'ils traitent, notamment en ce qui concerne 
le niveau semantique : il est ainsi possible de developper des programmes ne traitant 
qu'une partie des donnees contenues dans un document XML, ou de concevoir des 
noms d'elements satisfaisant aux exigences de nommage de plusieurs applications. 



Etape 5 - Finaliser la semantique du balisage 

Chapitre 5 

La question du nommage des elements et attributs XML est comme un curseur qu'il 
faudrait positionner entre deux extremes representant deux qualites differentes : d'un 
cote, une bonne representation de la donnee et, de 1' autre, une bonne representation 
des traitements, comme cela est illustre a la figure 5-1. 



Figure 5-1 

Le nom d'un objet XML peut 
representer deux types opposes 
de semantique. 
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Par exemple, une structure date constituee de la seule balise date peut suffire, comme 
dans <date>23 mai 1959</date>, mais si Ton veut traiter le contenu de cette date, il 
vaudra mieux utiliser trois sous-elements pour les jour, mois et annee, tels que : 

I <date><jour>23</jour><mois>mai</mois><annee>1959</annee></date> 

ou encore 

I <datexj j>23</j j><mm>05</mm><aa>1959</aax/date> 

Dans cette toute derniere forme, on a remplace le nom du mois par son numero : si 
cette date est de ce fait moins facile a lire naturellement, elle y gagne cependant en 
capacite de traitement. 

C'est toutes ces questions que nous etudions dans les sections suivantes de ce chapitre. 



Type et semantique 

Type et semantique designent deux caracteristiques complementaires d'un objet. 

Le type d'une donnee est sa nature physique : une date, un nombre decimal, entier, 
reel, positif ou negatif, une chaine de caracteres, etc. sont autant de types qui fournis- 
sent plus ou moins directement des indications sur la nature de l'information. Ces 
types permettent de la reconnaitre et de la controler. En XML, un type est simple 
(c'est-a-dire que la donnee s'ecrit directement sans avoir besoin de sous-elements, un 
nombre entier par exemple) ou complexe (des sous-elements sont necessaires pour 
decrire la donnee, c'est le cas de notre balise date ci-dessus). 

La semantique est une information complementaire qui definit la signification appli- 
cative de la donnee. De quelle date s'agit-il ? Qy'est-ce quelle determine ? A quoi 
sert-elle ? Ecrire <date>23 mai 1959</date> ou <date>vingt-trois mai mille 
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neuf cent cinquante neuf</date> permet a la seule lecture de savoir qu'il s'agit 
d'une date, mais preciser <date-de-naissance>23 mai 1959</date-de-naissance> 
indique a coup sur qu'il s'agit d'une date de naissance, meme en ignorant tout du 
schema qui valide un tel document XML. 

On le verifie, XML a toujours offert une bonne expression de la semantique, mais 
pas du type. En comparaison, le couple (colonne, type) du relationnel fait corres- 
pondre une semantique (le nom de la colonne) a son type, par exemple colonne 
Date_de_naissance et type date. Cependant, cette correspondance (sens, type) est 
limitee par l'organisation en deux dimensions du modele relationnel (table, colonne). 
Les emboitements des elements XML offrent infiniment plus de souplesse, en parti- 
culier depuis l'introduction des schemas. 

En effet, grace aux travaux realises pour XML Schema, le type des elements peut 
desormais non seulement etre complementaire de la semantique mais lui etre associe 
implicitement ou explicitement. On utilise done les noms d'elements de son choix, 
tels que date-de-naissance, mais on specifie de plus que cette date de naissance est 
d'un certain type. On peut ainsi la faire figurer selon une forme predefinie : celle du 
type (par exemple sous la forme 19590523). II n'est des lors plus besoin de sous-ele- 
ments pour que les programmes sachent a la fois controler la validite de cette donnee 
et la manipuler en tant que date. 



Exploiter le type et la semantique 



Exprimer le type et la semantique grace aux schemas XML est une chose, les 
exploiter en est une autre. 

Comme nous l'avons dit, XML transporte naturellement la semantique : la seule lec- 
ture des elements et des attributs suffit en general. Cependant, XML ne transporte 
pas naturellement le type. 

On est confronte aux quatre cas de figure suivants. 

Cas n°l : le document XML est simplement bien forme. II n'y a aucun transport des 
types. Seule la semantique des donnees apparait au travers des noms des elements. 

<?xml version="1.0"?> 
<partenai res> 
<partenai re> 
<nom>La bonne eto"Me</nom> 
<horai res> 
<ouverture>7</ouverture> 
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<f e rmetu re>20</f e rmetu re> 

<jours>12345</jours> 
</horai res> 
<adresse> 

<rue>ZI des Arbihres</rue> 

<vi 1 1 e>Sai nt-Nazai re</vi 11 e> 
</adresse> 
<telephone> 

<pays>33</pays> 

<region>2</region> 

<numero>35604289</numero> 
</telephone> 
</partenai re> 
</partenai res> 

Cas n°2 : on transmet le type des donnees via un attribut intitule type. Une applica- 
tion receptrice sera done en mesure de controler le type des donnees. Le type ainsi 
transmis s'exprime en utilisant les noms standards d'un catalogue connu (ici, nous 
avons utilise le catalogue des types de base de XML Schema) ou ceux d'un catalogue 
specifique a Implication. 

<?xml version="1.0"?> 

<partenai res xml ns : xs="http : //www . w3 . org/2001/XMLSchema" 

xml ns : xsi ="http : //www. w3 . org/2001/XMLSchema-i n stance "> 
<partenai re> 
<nom xsi :type="xs:string">La bonne etoile</nom> 
<horai res> 
<ouverture xsi :type="xs:int">7</ouverture> 
<fe rmetu re xsi :type="xs:int">20</fe rmetu re> 
< jours xsi :type="xs:int">12345</jours> 
</horai res> 
<adresse> 
<rue xsi : type="xs:string">ZI des Arbihres 
</rue> 

<ville xsi :type="xs:string">Sai nt-Nazai re 
</ville> 
</adresse> 
<telephone> 
<pays xsi :type="xs:int">33</pays> 
<region xsi :type="xs:int">2</region> 
<numero xsi :type="xs:int">35604289</numero> 
</telephone> 
</partenai re> 
</partenai res> 
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Cas n°3 : le document XML fait reference au schema XML qui en controle la vali- 
dity. La connaissance du type des donnees necessite de savoir lire un schema XML et 
que ce dernier soit accessible.. 

<?xml version="1.0"?> 

<partenai res xml ns : xsi ="http : //www. w3 . org/2001/XMLSchema-i nstance" 
xsi : noNamespaceSchemaLocati on="partenai res . xsd"> 
<partenai re> 
<nom>La bonne etoile</nom> 
<horai res> 
<ouverture>7</ouverture> 
<fermeture>20</fermeture> 
<jours>12345</jours> 
</horai res> 
<adresse> 
<rue>ZI des Arbihres</rue> 
<vi 1 1 e>Sai nt-Nazai re</vi 11 e> 
</adresse> 
<telephone> 
<pays>33</pays> 
<region>2</region> 
<numero>35604289</numero> 
</telephone> 
</partenai re> 
</partenai res> 

Cas n°4 : voici un extrait du PSVI de notre document partenai res. xml. Le PSV1 
est un document XML qui contient l'integralite du document XML originel et son 
schema associe. Ici, nous voyons que pour le seul element ouverture, on obtient un 
nombre important d'informations parmi lesquelles : son contenu initial, son type et 
la forme lexicale normalisee de son contenu. Les elements et donnees du document 
XML originel sont completement encapsules par un nouveau type de balisage, en 
cours de normalisation, qui est celui du PSVI. Cette forme a l'avantage de trans- 
porter toute l'information au sein d'un meme et seul document XML... II n'est tou- 
tefois pas evident quelle soit simple a lire par les utilisateurs. On a ici un maximum 
d'information de typage en conservant la semantique du balisage initial et 1' exploita- 
tion d'un tel document XML par des programmes est optimale.. 

<element baseURI="file:///C:/exemplesXSV/partenai res. xml " 

1 ocal Name="ouvertu re" 

nil="false" 

p : schemaNormal i zedVal ue="7" 

p : val i dati onAttempted="f ul 1 " p : val i dati onContext="gl" 

p : val i di ty="val i d"> 
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<text content="7"/> 

<namespace namespaceName= 

*»"http : //www . w3 . org/XML/1998/namespace" 

prefix="xml "/> 

<namespace namespaceName= 

"http : //www . w3 . org/2001/XMLSchema-i nstance" 
prefix="xsi "/> 

<p:atomic ref="xsd. .type.int" i : nil="true"/> 
</element> 



Concept psvi 

On note PSVI pour Post Schema Validation InfoSet. II s'agit d'un ensemble d'informations obtenu par la 
validation de schema. II contient la totalite du document XML parse et la totalite des informations issues 
du schema ou calculees pendant I'operation de validation (exemple : les valeurs lexicales canoniques). 
Bien qu'informelle, vous trouverez une definition precise du PSVI a I'URL http://www.w3.org/2001/ 
05/serialized-infoset-schema.html et du schema XML correspondant a I'adresse 
http://www.w3.org/2001/05/PSVInfoset.xsd. 



VOCABULAIRE Validation de schema 

L' expression validation de schema designe la validation d'un document XML eu egard a son schema XML. 



VOCABULAIRE Forme lexicale normalisee, ou canonique 

La forme lexicale normalisee d'une donnee designe sa representation lexicale (c'est-a-dire sa forme tex- 
tuelle dans un fichier) obtenue quand on tient compte du type de la donnee. Le cas le plus typique est la 
representation des nombres : si on ecrit +003 . 1200 dans un document XML et que Ton a declare cette 
donnee comme etant de type decimal, sa forme lexicale normalisee sera 3.12. Le tome 2 de la recom- 
mandation XML Schema precise les formes normales lexicales des types accept.es par XML Schema. Vous 
trouverez cette recommandation a I'URL http://www.w3.org/TR/xmlschema-2/. 



Manieres d'exprimer la semantique 

Pour ce sujet, nous allons partir d'exemples que nous decrivons brievement. 
Exemple 1 

<hl>La bonne etoile</hl> 

<p>Horai res : Ouvert de 7 heures a 20h, tous les jours sauf le WE</p> 

<p>Adresse : ZI des Arbihres Saint-Nazai re</p> 

<p>Tel : +33.2.35.60.42.89</p> 
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Les elements p et hi sont traditionnellement utilises pour marquer des paragraphes 
et des titres de niveau 1 dans des documents (et en particulier en HTML). 

II s'agit typiquement de balises qui n'informent que tres peu, voire pas du tout sur la 
nature du contenu textuel qu'elles transportent. II s'agit d'un balisage dit « de type 
document ». 

Leur role essentiel est de provoquer des ordres de composition particulier : une mise 
en exergue pour les titres, leur renvoi en table des matieres et une composition simple 
pour les paragraphes. . . 

La semantique de ces elements est mono-applicative, a savoir que cela ne concerne 
que les seules applications de composition des documents, de mise en page. 

Exemple 2 

<hl xsi :type="nom-du-partenai re">La bonne etoile</hl> 

<p xsi :type="horai res-ouverture">Ouvert de 7 heures a 20h, tous les 

jours sauf le WE</p> 

<p xsi :type="adresse">ZI des Arbihres Saint-Nazai re</p> 

<p xsi :type="telephone">+33 .2 . 35 .60.42 .89</p> 

En ajoutant l'attribut type, on apporte une information relative au type de contenu. 

Le document XML devient nettement plus comprehensible pour le lecteur humain 
et la semantique des donnees est transportee jusqu'a Implication de composition. 
Cette derniere pourra, a sa guise, l'utiliser ou l'ignorer. 

On peut supprimer une partie du contenu textuel et laisser le soin a l'application de 
produire des textes complementaires tels que les prefixes Horaires :, Adresse : ou 
encore Tel :. En rendant le contenu textuel linguistiquement plus neutre, on facilite 
l'echange entre systemes et les operations de transformation. 

Exemple 3 

<hl xsi :type="nom-du-partenai re">La bonne etoile</hl> 
<p xsi :type="horai res-ouverture"xvar varType="ouverture">7</var> 
<var varType="fermeture">20</varxvar varType=" jours">12345</var> </p> 
<p xsi :type="adresse"xvar varType="rue">ZI des Arbihres</var> 

<var varType="vi 1 1 e">Sai nt-Nazai re</varx/p> 

<p xsi :type="te1ephone"xvar varType="pays">33 

</varxvar varType="region">2</varxvar varType="numero">3 56042 89 

</varx/p> 

Ici on conserve le meme balisage principal (les hi et p de l'application de composi- 
tion) et on developpe un sous-balisage pour decrire la semantique des donnees. 
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L' element var sert de fourre-tout transportant la semantique des donnees jusqu'a 
l'application de composition, a qui revient la charge de construire des phrases com- 
prehensibles pour le lecteur. 

Linteret ici, c'est de pouvoir developper des applications multilingues a partir d'un 
meme fonds de donnees ; en revanche, il n'est pas aise de savoir quelle partie de 
l'application doit operer la transformation du contenu. Cette question sera abordee 
au chapitre 7. 

Exemple 4 

<partenai re> 
<nom>La bonne etoile</nom> 
<horai res> 

<ouverture>7</ouverture> 

<fe rmetu re>20</fe rmetu re> 

<jours>12345</jours> 
</horai res> 
<adresse> 

<rue>ZI des Arbihres</rue> 

<vi 1 1 e>Sai nt-Nazai re</vi 1 1 e> 
</adresse> 
<telephone> 

<pays>33</pays> 

<region>2</reg"ion> 

<numero>35604289</numero> 
</telephone> 
</partenai re> 

Ici, le balisage est exclusivement oriente donnees. Tout le balisage de type presenta- 
tion (les elements p et hi) a disparu. 

L'application doit prendre en charge une transformation complete des donnees et des 
elements XML : le texte final doit etre synthetise a partir de la semantique induite 
par les noms des elements XML qui doivent etre mis en correspondance (trans- 
formes) avec des elements de presentation. 

La transformation des elements de ce document XML en elements de presentation 
(en HTML par exemple) peut ne pas etre evidente. 

La semantique des donnees ne passe que par les seuls elements XML que l'applica- 
tion doit comprendre dans leur integralite et individuellement. 
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Exemple 5 

<partenai re> 

<nom>La bonne etoile</nom> 
<heure-ouverture>7</heure-ouverture> 
<heure-fermeture>20</heure-fermeture> 

<adresse>...</adresse> 

<tel ephone>...</tel ephone> 
</partenai re> 



ou 



<partenai re> 

<nom>La bonne etoile</nom> 
<heu re -ouvertu re-en- semai ne>7 
</heure-ouverture-en-semaine> 
<heure-fermeture-en-semai ne>20 
</heure-fermeture-en-semaine> 
<adresse>...</adresse> 
<tel ephone>...</tel ephone> 
</partenai re> 



ou 



<partenai re> 

<nom>La bonne etoi 1 e</nom> 
<heu re -ouvertu re-en- semai ne-en-vacances>7 
</heure-ouverture-en-semaine-en-vacances > 
<heure-fermeture-en-semai ne-en-vacances >20 
</heure-fermeture-en-semaine-en-vacances > 

<adresse>...</adresse> 

<tel ephone>...</tel ephone> 
</partenai re> 

Dans ce dernier exemple, nous montrons qua un element peut etre attachee une 
semantique plus ou moins precise via son nom ou un attribut. Les noms d'elements 
heure-ouverture, heure-ouverture-en-semaine et heure-ouverture-en-semai ne- 
en-vacances sont, dans cet ordre, classes du plus vague au plus precis. 

Au travers de ces exemples, on montre la diversite des cas de figure, depuis un bali- 
sage oriente document ressemblant a du HTML jusqu'a des balisages orientes donnees 
mettant en valeur soit la semantique, soit les types, ou bien les deux. 
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Ces nombreuses possibilites de XML indiquent qu'il faut essayer dans la mesure du 
possible de choisir les noms et la structure des elements en tenant compte de leur 
contexte d'utilisation : ainsi reservons-nous au monde du document des modeles de 
balisage orientes document et au monde du calcul ceux orientes donnees. 



Adapter les structures au contexte 

On comprend que la structure XML des exemples fournis a la section precedente (a 
l'exception du premier cas) transporte peu ou prou la meme semantique. Finalement, 
il semble bien que seule change la forme. 

La difference entre toutes ces formes de balisage tient dans leur adequation avec leur 
contexte d'utilisation : quels sont les balisages et vocabulaire bien adaptes ? 

Le contexte d'utilisation est la partie de 1' application qui va etre concernee par les 
donnees suivantes : est-ce l'affichage qui est en question ? la composition ? le 
transport ? la transformation ? le stockage ? 

Comme cela apparait a la figure 5-2, il est difficile de parler d'un seul et unique trai- 
tement. Tout au long de leur cycle de vie, les donnees XML vont etre au service de 
plusieurs applications ainsi que nous l'avons evoque des le chapitre 1. 



m Production 
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Applications d'edition et 
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Figure 5-2 La forme XML doit etre adaptee au contexte d'utilisation. 



A l'examen de cette figure, on comprend mieux pourquoi il est impossible d'imaginer 
qu'une seule forme de balisage XML suffira a satisfaire tous les cas de figure car la 
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mise en oeuvre de XML s'accompagne obligatoirement de developpements de pro- 
grammes de transformation de l'information. 

Parmi les formes montrees a la section precedente, certaines conviennent mieux au 
stockage (les cas 4 et5 qui exposent bien la semantique), d'autres a 1'affichage (cas 1 
qui utilise un balisage oriente document) et enfin d'autres encore au transport (cas 2 
et 3 qui exposent prioritairement le typage des donnees). S'il existe des tendances gene- 
rales en ce qui concerne ces formes, on ne peut toutefois affirmer in abstracto que telle 
forme est meilleure que telle autre : il faut toujours tenir compte du contexte applicatif 

On retiendra toutefois les directives suivantes : 

• Au niveau du stockage, tant le nom des elements que leur hierarchie ne doivent 
pas dependre directement d'un programme en particulier. Par exemple, chercher a 
etablir des equivalences directes entre noms d'elements XML et ceux de classes 
Java est un (tres) mauvais choix conceptuel - nous en expliquerons les raisons 
dans la section suivante. 

• Le modele de stockage doit etre le plus representatif possible du modele concep- 
tuel des donnees, lui-meme potentiellement different de celui necessaire aux 
applications. Laffichage en HTML d'un tableau de donnees en est un exemple 
caracteristique : il est evidemment tres reducteur de stocker dans une base de 
donnees XML ledit tableau sous sa forme HTML. II est preferable de proceder a 
l'aide d'un balisage « informatif » qui fera ressortir la logique des donnees a l'inte- 
rieur du tableau. En d'autres termes, pour decrire un tableau de boulons, il est 
plus puissant d'utiliser les balises <bou"lon>, <diametre>, <"longueur>, 
<code_article>... que les <table>, <tr>, <td> du langage HTML. 

• Afin de ne pas trop rigidifier le modele de stockage au travers des structures d'ele- 
ments, vous pouvez faire passer tout ou partie de la semantique par des valeurs 
d'attributs. 

Outrepasser le principe des objets metier Java 

Le principe des objets metier reside dans la mise en correspondance des noms d'ele- 
ments XML et des classes Java qui en assurent le traitement. De nombreuses raisons 
nous amenent a critiquer cette maniere de concevoir les applications : 

• II est dangereux de lier deux mondes aussi differents que ceux des donnees et des 
traitements. Rendus dependants, ni le modele de donnees, ni les traitements ne 
peuvent plus evoluer librement, ce qui serait contraire a l'esprit de XML et de 
toute architecture applicative evolutive. 

• En XML, la signification des noms d'elements peut etre contextuelle. Dans nos 
exemples, 1' element ho ran re a differentes semantiques selon que ses parents sont 
ouverture, fermeture ou encore vacances. On peut supposer que les traitements 
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appliques aux donnees seront differents dans chacun de ces trois cas. II faut pou- 
voir associer plus d'un programme a l'element horai re. 

• En XML, un seul nom d'element ne suffit pas a un programme : la connaissance 
des valeurs d'attributs, sous-elements, voire elements parents, peut se reveler deci- 
sive pour les programmes de traitement. Comment faire lorsque seul le nom de 
l'element est associe a un, et un seul, programme ? 

• Associer brutalement un nom d'element a une classe bloque toute evolution du 
schema XML. En effet, lors de la revision d'un schema, un nom d'element peut 
etre remplace par un autre, change en attribut, deplace dans la structure, et il peut 
meme etre transforme semantiquement. II faut que ces modifications soient faites 
tout en conservant les anciens traitements : anciens et nouveaux programmes doi- 
vent cohabiter malgre les modifications apportees au balisage. 

• Linverse est vrai, il faut parfois disposer de plusieurs programmes differents pour 
un meme element, le choix entre les traitements pouvant par exemple intervenir 
au vu de la valeur d'un attribut. 

La bonne architecture consiste done a utiliser des techniques associant de maniere 
logique les elements aux programmes de traitement. Y proceder par le seul jeu des 
noms d'elements est voue a l'echec. Les elements peuvent etre associes aux pro- 
grammes de traitement par le biais d'un tableau comportant quatre colonnes : une 
premiere colonne sert a lister un ou plusieurs nom(s) d'element(s), une deuxieme 
colonne sert a specifier des conditions contextuelles pour ces elements, dans les troi- 
sieme et quatrieme colonnes on specifie le programme a executer quand la balise 
ouvrante (respectivement fermante) est rencontree. 



HlSTOIRE CALS 

CALS est I'acronyme de Computer Aided Logistics Support. Ce projet du departement de la Defense ame- 
ricaine est historiquement celui qui permit, en 1988, le decollage de SGML. Son impact sur I'essor de 
SGML fut tel que le mot CALS est devenu a une epoque synonyme de SGML. Un peu comme Frigidaire 
etait synonyme de refrigerateur. II en est reste un modele de tableau dit « le modele CALS » que tous les 
editeurs SGML/XML mettent en oeuvre nativement. 



Dans l'exemple du tableau 5-1, nous presentons un exemple typique de specification 
de traitement d'un flot XML. Les elements XML concernes sont ceux qui definis- 
sent un tableau selon le modele CALS. Cet exemple presente tous les cas de figure 
que nous avons enumeres plus haut, a savoir : 

• L'element n'est associe a aucun traitement. C'est le cas des elements tabl e, thead, 
tbody et tf oot. 

• Les elements subissent tous le meme traitement. C'est le cas des elements tabl e, 
thead, tbody et tfoot qui ont tous ete ecrits dans une meme cellule du tableau. 
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Les elements subissent un traitement conditionne a un contexte. C'est le cas des 

elements title, row et entry, dont les differents contextes apparaissent dans la 

deuxieme colonne sous la forme d'expressions Xpath. 

Les elements associes a des traitements tant sur la balise ouvrante que sur la balise 

fermante. C'est le cas des elements tgroup, row et entry. 

Les valeurs attributs de 1' element ou de ses parents modifient le traitement a 

appliquer. C'est le cas de 1' element entry. 





Tableau 5-1 


Exemple de specification de traitement d'un flot XML 




Element Contexte Balise ouvrante Balise fermante 


<table> 
<thead> 
<tbody> 
<tfoot> 








<title> 


Table/title 


Utiliser le style ti tl e : tab! e 

Ce style doit chevaucher les colonnes si I'attribut 
pgwide est present sur I'un des elements parent de 
title. 




<tgroup> 




Inverser les branches enfant tf oot et tbody. 

Inserer un tableau dans le document ayant le nombre 
de colonnes specifie par I'attribut col s, chevauchant 
les colonnes de la page si I'attribut pgwi de a ete uti- 
lise. . . Et on peut trouver ici toute une serie de specifica- 
tions de mise en forme du tableau dependant des 
valeurs des attributs trouves sur cette balise dans le 
document XML. 


Arreter le tableau. 


<colspec> 




ReconnaTtre les caracteristiques des colonnes. Les stac- 
ker pour les utiliser ensuite dans la fabrication du 
tableau final. 




<spanspec 
> 




Stacker les caracteristiques de fusion de cellules defi- 
nies via cet element. 




<row> 


thead/row 


Inserer une rangee d'en-tete qui se repete sur chaque Terminer la rangee. 
page. 


<row> 


tfoot/row 


Inserer une rangee de pied de tableau. 


Terminer la rangee. 


<row> 


tbody/row 


Inserer une rangee normale. 


Terminer la rangee. 


<entry> 


./[@align= "char"] 
./©namest 


Inserer une cellule contenant un paragraphe p dans la 
colonne specifiee par la valeur de I'attribut namest. 

Aligner le texte sur le caractere specifie par I'attribut 
charoff. 


Terminer la cellule. 
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Tableau 5-1 


Exemple de specification de traitement d'un flot XML 




Element Contexte Balise ouvrante Balise fermante 


<entry> 


./©namest Inserer une cellule contenant un paragraphe p dans la 
colonne specifiee par la valeur de I'attribut namest. 


Terminer la cellule. 


<entry> 


./[@align= "char"] 
./©spannames 


Inserer une cellule contenant un paragraphe p. 

Aligner le texte sur le caractere specifie par I'attribut 
charoff. 

Fusionner la cellule selon la specification spannames. 


Terminer la cellule. 


<entry> 


./©spannames Inserer une cellule contenant un paragraphe p. 

Fusionner la cellule selon la specification spannames. 


Terminer la cellule. 


<entry> 


./[@align= "char"] 


Inserer une cellule contenant un paragraphe p. 

Aligner le texte sur le caractere specifie par I'attribut 
charoff. 


Terminer la cellule. 


<entry> 




Inserer une cellule contenant un paragraphe p. 


Terminer la cellule. 



Cet exemple montre bien comment, en XML, il est necessaire de pouvoir etablir une 
carte d'association, parfois sophistiquee, entre elements et traitements associes. 

Nous avons pris ici le cas du balisage d'un tableau ; c'est certes un cas typique, mais 
cela eut ete la meme chose avec tout autre type de donnees. 



Utilisation des attributs pour passer la semantique 

En general, l'introduction de la semantique par les noms d' elements reduit considera- 
blement les possibilites d' evolution des schemas. Nous allons en expliquer les raisons. 

L'interet qu'il y a a transmettre la semantique des donnees est evidemment de faire 
passer a un programme recepteur une information la plus precise possible, et done 
d'avoir un grand choix. Si on decide de faire passer la semantique par les elements, 
tout nouveau nom devra etre formellement declare dans la DTD ou le schema XML 
associe au document : croyant enrichir la semantique du document XML, on touche 
en realite sa structure. Or, cela n'est pas la meme chose : structure et semantique sont 
deux dimensions differentes. 

En utilisant les attributs, on fait varier la semantique des donnees sans toucher a leur 
structure. On peut des lors exprimer un grand nombre de possibilites sans avoir a 
ecrire autant de schemas. On diminue la complexite des applications, le nombre de 
revisions des DTD et les risques lies a la cohabitation des schemas. 
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Si Ton peut disposer de plusieurs semantiques a schemas egaux, alors l'introduction 
d'une nouvelle semantique ne touchera que tres localement les programmes deja 
ecrits, ce qui n'est pas le cas quand on change une structure. 

Quand on fait passer la semantique par le nom de I'element, une seule semantique 
est exprimee. Quand on utilise les attributs, on fait passer autant de semantiques que 
Ton veut. Nous donnons des exemples ci-apres. 

Exemple 1 : Cas ou il n'y a pas d'attribut. 

<heure-ouverture>8h30 tous les jours sauf le samedi ou l'on ouvre a 7h30 
</heure-ouverture> 

ou 
<heure-ouverture>8 . 30</heure-ouverture> 

La semantique passe uniquement par le nom de I'element. Tout changement de 
semantique entrainera une revision de la DTD ou du schema XML de l'application. 

Remarquons toutefois qu'entre les deux cas de figure presentes ici, et utilises tout au 
long de ce tableau, la precision des donnees transmises n'est pas identique. 

Exemple 2 

<heure-ouverture contenuType="texte"> 8h30 tous les jours sauf le samedi 
ou l'on ouvre a 7h30</heure-ouverture> 

ou 

I <heure-ouverture contenuType="numerique">8. 30</heure-ouverture> 

Admettons que l'on souhaite autoriser la saisie d'un texte libre ou d'une heure a 
l'interieur de I'element. Admettons que cette information soit susceptible de passer 
au travers d'un programme de traitement qui aura un comportement different selon 
qu'il detecte une expression textuelle ou une indication numerique d'heure. 

Nous avons alors tout interet a ajouter un attribut, comme nous l'avons fait ici avec 
1' attribut contenuType, permettant de specifier le type « applicatif » de cette informa- 
tion. En ne limitant pas notre modele aux seuls types de XML Schema, on signifie 
que l'on se reserve le droit de creer son propre catalogue de types. La charge incombe 
ensuite aux programmes d'en controler la coherence. Cela n'est pas un mal, le cata- 
logue des types de XML Schema est souvent trop restrictif pour nous en contenter. 
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Exemple 3 



<heure roleType="ouverture" contenuType="texte">8h30 tous les jours 

sauf le samedi ou 1'on ouvre a 7h30 

</heure> 



ou 



I] <heure roleType="ouverture" contenuType="numerique">8. 30</heure> 

Ici, nous faisons la distinction entre un attribut qui va qualifier 1' element XML et un 
attribut qui va qualifier l'usage de la donnee pour une application. 

L'attribut roleType vient qualifier 1' element heure-ouverture, desormais reduit a un 
nom tres generique. Ici, on precise qu'il s'agit d'une heure d'ouverture. 

L'attribut contenuType vient qualifier la donnee pour l'application qui la traite. Ici, on 
l'utilise pour preciser s'il s'agit d'une chaine de caracteres ou d'une valeur numerique. 

Exemple 3 

<heure roleType="ouverture" contenuType="numerique" 

applicType="LMM3VD">8.30</heure> 

<heure roleType="ouverture" contenuType="numerique" 

applicType="S">7. 30</heure> 

Afin de faire passer exactement le meme niveau d'information entre les deux cas de 
figure qui servent de support a nos exemples, nous ajoutons desormais un attribut, 
appl i cType, permettant de preciser le domaine d'applicabilite de l'element heure. 

Ici, on precise dans le premier cas que l'heure d'ouverture est applicable du lundi au 
dimanche sauf le samedi, et dans le second que l'heure d'ouverture precisee ne 
s'applique que le samedi. 



Technique Notion d'applicabilite 

La notion d'applicabilite des donnees est probablement aussi importante que celle de type. En effet, la jus- 
tesse d'une donnee depend parfois de son contexte d'utilisation. Dans le domaine mecanique, il existe de 
nombreux cas de donnees vraies dans un certain contexte et fausses dans d'autres. Le secteur automobile 
est riche de ces cas puisque les constituants d'une voiture varient enormement d'un modele a un autre, en 
fonction de I'endroit, par exemple, ou la voiture est fabriquee. L'applicabilite consiste a indiquer le con- 
texte de validite d'une information. Parler de domaine de validite d'une donnee reviendrait au meme. 



Etapes de la demarche de modelisation 

Premiere partie 

Le balisage propose dans le dernier des exemples precedents offre a la fois souplesse, 
precision et liberte d'adaptation : 

• souplesse en raison du tees grand nombre de cas de figure qu'il prend finalement 
en compte ; 

• precision car plusieurs semantiques sont transmises ; 

• liberte d'adaptation car de nouvelles valeurs et possibilites sont tees facilement 
utilisees. 

Enfin, ce type de balisage est lui-meme generique, et 1' experience montre qu'il peut 
etre generalise a presque tous les elements d'une DTD ou d'un schema. 

Ainsi, quand on concoit un schema XML, on peut toujours partir du principe que les 
elements se verront attribuer systematiquement trois proprietes : 

• un attribut de precision pour affiner la semantique portee par le nom de l'element, 
ici, 1'attribut rol eType ; 

• un attribut de specification du domaine de validite de l'element, ici l'attribut 
applicType ; 

• un attribut de specification destine a l'application qui recoit les donnees, ici 
l'attribut contenuType. 

En ce qui concerne les valeurs autorisees pour ces attributs, il n'y a pas de regie lexi- 
cale particuliere. C'est a vous de definir les regies qui conviennent a vos propres cas 
de figure. 



En resume... 

Dans ce chapitre, nous avons aborde le probleme de la relation des elements XML 
avec les programmes qui doivent les traiter. 

Nous avons vu que la mise en correspondance directe des noms d'elements XML 
avec ceux des programmes qui les traitent est une mauvaise conception. 

Nous avons explique la difference entre structure et semantique, et propose plusieurs 
solutions pour transmettre la semantique des elements aux applications. 

En faisant attention a bien dissocier les donnees des traitements et en utilisant des 
formes XML bien choisies, il est possible d'augmenter sensiblement la souplesse et la 
perennite des applications. 

Au chapitre suivant, nous allons etudier le cas d'utilisation des variantes de modeles. 
D'une part, nous allons montrer pourquoi ces variantes sont presque toujours neces- 
saires, et d'autre part en quoi elles ne doivent pas creer d'interferences dans les appli- 
cations. 
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Etape 6 - Produire les 
variantes des schemas XML 



Nous allons maintenant aborder la facon dont il convient de gerer les variantes des 
modeles de base. A ce stade de la conception d'un modele, les schemas XML sont 
suffisamment connus et stabilises pour que les consequences de leurs evolutions 
futures puissent etre envisagees. 

II serait en effet reducteur d'imaginer que les modeles XML n'evolueront pas une fois 
l'application developpee. La souplesse de XML, qui permet de faire cohabiter plusieurs 
versions d'un meme modele au sein d'une meme application, est en general exploitee. 



Pourquoi des variantes ? 



Deux series de raisons justifient l'existence de variantes. Une premiere est fournie par 
XML lui-meme tandis que la seconde provient de la nature de la matiere manipulee : 
l'information. 

Raisons liees a la nature de XML 

Un document XML est loin d'avoir une seule forme et peut exister sous des formes 
aussi differentes que : 

• Un document de base bien forme resultant d'une saisie manuelle ou d'une genera- 
tion automatique. 
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• La forme canonique XML du document XML de base : celle dans laquelle le 
parseur a par exemple ajoute les valeurs d'attributs par defaut ou imposees. 

• La forme canonique lexicale du document XML de base : celle dans laquelle le 
parseur a modifie le contenu des elements et attributs en tenant compte des types 
simples qui leur ont ete affectes via le schema XML. Les blancs sont par exemple 
reduits quand ils sont en surnombre dans les chaines de caracteres, les zeros de 
tete et de queue sont ecretes dans les nombres, les booleens et 1 remplaces par 
les mots fake et true, etc. 

• La forme consolidee, ou expansee, du document XML de base : les eventuels 
sous-documents inclus par XInclude sont alors physiquement inclus, les entites 
textuelles sont remplacees par leur contenu, etc. 

• La forme PSVI, pour Post Schema Validation InfoSet, du document XML de 
base. II s'agit d'une version du document XML dans laquelle on introduit la tota- 
lite des definitions deductibles du schema associe. 

Raisons liees a la nature de ('information 

La seconde serie de raisons est relative aux principes memes que devrait respecter 
tout systeme d'information : souplesse, adaptabilite, capacite a etre connecte a 
d'autres systemes, etc. Autrement dit, elle est relative a : 

• revolution naturelle des fonctions du systeme ; 

• l'extension du jeu de donnees pris en charge par I'application ; 

• l'amelioration de la qualite des donnees ou des formats d'echange de donnees 
entre applications ; 

• la prise en charge de differentes demandes specifiques de clients (au sens com- 
mercial du terme « client ») ; 

• les regies metier specifiques d'un projet ; 

• le besoin de disposer de plusieurs formats de stockage (pour differents medias) ; 

• le besoin de permettre a I'application de manipuler et stocker momentanement 
des formats XML legerement differents des formats officiels. Par exemple, pou- 
voir stocker des documents « bien formes », mais pas encore valides... 

• l'enrichissement des structures XML par des metadonnees de gestion ou de traca- 
bilite de la qualite ; 

• la correction de bogues du modele : en XML, il arrive que les modeles soient 
bogues quand, par exemple, on s'apercoit a l'usage que telle structure est impossi- 
ble a realiser alors quelle devrait l'etre, tandis que d'autres sont interdites quand 
elles devraient etre autorisees. 
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Un cas concret 



Nous allons utiliser dans ce chapitre le cas concret de PiloteWeb. Nous decidons de 
modifier le schema sites .xsd afin que les utilisateurs puissent ajouter un prenom a 
l'interieur du champ nom. 

Nous souhaitons indifferemment pouvoir obtenir des documents XML de la forme : 

<si :sites> 

<si:site unique-id="ID000000"> 
<si :nom>Nicolas le Panda</si :nom> 

<si:photo nom="pl" format="gif"/> 
<si :position> 
<si : x>48 . 7494</si : x> 
<si : y>-2 . 1108</si : y> 
</s"i :position> 
</si : site> 
</si : sites> 

ou de la forme : 

<si :s"ites> 

<si:site unique-id="ID000000"> 

<si :nomxsi :prenom>Nicolas</si :prenom> le Panda</si :nom> 

<si:photo nom="pl" format="gif "/> 
<si :position> 
<s"i : x>48 . 7494</si : x> 
<si : y>-2 . 1108</si : y> 
</si :position> 
</si :site> 
</si : sites> 

Nous allons etudier les differentes manieres d'identifier les schemas correspondant a 
ces variantes. 



Comment identifier les variantes ? 

Qui dit variantes, dit schemas differents ! La maniere de gerer l'identification de ces 
schemas dependra des deux cas de figure suivants : 

• soit le schema definit un vocabulaire sans espace de noms cible ; 

• soit le schema definit un vocabulaire dans un espace de noms cible. 

Nous allons successivement etudier Fun et 1' autre cas. Dans le texte ci-apres, nous 
utilisons les expressions de schema initial et de schema variant. 
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Schema sans espace de noms cible 

Si le vocabulaire du schema initial n'a pas ete projete dans un espace de noms, celui 
du schema variant ne le sera pas non plus. II suffit des lors d'adapter l'attribut 
noNamespaceSchemaLocation porte par les elements racines des documents XML 
concernes. 

Dans l'exemple suivant, le premier document XML reference le fichier contenant 
sites . xsd, tandis que le second reference la variante de ce schema contenue dans le 
fichier si tesVari ante . xsd. 

Void le document XML referencant le schema initial : 

<?xml version="1.0" encoding="UTF-8"?> 

<si tes xml ns : xsi ="..." xsi : noNamespaceSchemaLocat i on="s i tes . xsd"> 
<site unique-id="pl"> 
<nom>Nicolas le Panda</nom> 
<position x="48.7494" y="-2 . 1108"/> 

<photo nom="http : //www. pi 1 oteWeb . com/pl . gi f " f ormat="gi f "/> 
</site> 
</sites> 

et le document XML referencant une variante du premier schema : 

<?xml version="1.0" encoding="UTF-8"?> 

<sites xml ns: xsi ="..." xsi :noNamespaceSchemaLocation="sitesVariante.xsd"> 

<site unique-id="pl"> 

<nomxprenom>Nicolas</prenom> le Panda</nom> 
<position x="48.7494" y="-2 . 1108"/> 

<photo nom="http : //www. pi 1 oteWeb . com/pl . gi f " f ormat="gi f "/> 
</site> 
</sites> 

Le passage a la variante revient done, le cas echeant, a modifier physiquement les 
documents XML auxquels la variante s' applique. Les anciens documents peuvent 
cohabiter avec les nouveaux. 

Schema avec un espace de noms cible 

Dans le cas ou le schema aurait un espace de noms cible, deux cas de figure se pre- 
sentent selon que le schema variant : 

• est une copie du schema initial : le nom de l'espace de noms cible peut alors etre 
conserve ou modifie ; 

• s'appuie sur les possibilites de redefinition de XML Schema : le nom de l'espace 
de noms cible doit etre conserve. 
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Le schema variant est une copie du schema initial 

Nous distinguerons les cas d'une revision (le nouveau schema remplace l'ancien) et 
d'une version (le nouveau schema cohabite avec l'ancien). 

Si la variante est une revision du schema initial, le nom de l'espace de noms est con- 
serve. Dans les documents XML concernes par cette revision, il faut changer l'URI du 
schema et le remplacer par celui du fichier contenant le schema variant (repere ©). 

<si:sites xmlns: si="sites" 

xml ns : xsi ="http : //www. w3 . org/2001/XMLSchema-i n stance" 
xsi : schemaLocation="sites sitesVariante.xsd"> <- © 
<si:site unique-id="ID000000"> 

<si :nomxsi :prenom>Nicolas</si :prenom> le Panda</si :nom> 
<si:photo nom="pl" format="gif"/> 
<s"i :position> 
<si : x>48 . 7494</si : x> 
<si :y>-2 . 1108</si :y> 
</si :position> 
</si :site> 
</si :sites> 

Si la variante est une nouvelle version du schema, on lui attribue un nouveau nom 
d'espace de noms. Dans les documents XML concernes par la nouvelle version, il faut 
remplacer les noms et URI de l'ancien schema par ceux de la variante (reperes O et ©). 

<si:sites xmlns: si="sitesVariante" <- O 

xml ns : xsi ="http : //www. w3 . org/2001/XMLSchema-i n stance" 
xsi :schemaLocation="sitesVariante sitesVariante.xsd"> <- © 
<si:site unique-id="ID000000"> 

<si :nomxsi :prenom>Nicolas</si :prenom> le Panda</si :nom> 
<si:photo nom="pl" format="gif"/> 
<si :position> 
<si : x>48 . 7494</si : x> 
<si : y>-2 . 1108</si : y> 
</si :position> 
</si : site> 
</si :sites> 

Dans un tel cas de figure, la question qui ne manquera pas de se poser est celle de la 
mise en commun des parties semblables des modeles et documents XML associes. 
Cela est possible en utilisant les mecanismes d'inclusion et redefinition de 
XML Schema (composants xsd: include, xsd: import et xsd: redefine). Nous 
allons voir ci-apres les cas de l'inclusion et de la redefinition. 
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Le schema variant est une redefinition du schema initial 

Avec une redefinition, on peut reutiliser sans les copier toutes les definitions du 
schema initial qui ne sont pas concernees par la variante. Linconvenient, c'est que 
l'espace de noms cible de la variante est forcement egal a celui du schema initial. 

Dans l'exemple suivant, on montre un schema initial et sa variante creee au moyen 
d'une redefinition. 

Le schema initial a ete rendu compatible avec les exigences de la fonction de redefi- 
nition de XML Schema ; c'est la raison pour laquelle il est different de celui presente 
au chapitre 5. Toutefois, il ne presente pas a proprement parler une variante du 
schema originel utilise dans PiloteWeb puisqu'il definit exactement les memes struc- 
tures et vocabulaires. Seule change la maniere dont sont definis les objets. 

<?xml version="1.0" encoding="UTF-8"?> 
<xs : schema xml ns : xs="http : //www. w3 . org/2001/XMLSchema" 
targetNamespace="sites" 
xmlns :sites="sites"> 
<xs:complexType name="nomType" mixed="true"/> 
<xs: element name="nom" type="sites: nomType"/> 
<xs:complexType name="photoType"> 

<xs: attribute name="nom" type="xs :anyURI" use="requi red"/> 
<xs: attribute name="format" type="xs:string"/> 
</xs : compl exType> 
<xs : compl exType name="si teType"> 
<xs:sequence> 
<xs: element ref="sites:nom"/> 

<xs: element name="photo" type="sites: photoType" minOccurs="0"/> 
<xs:element name="position"> 
<xs : compl exType> 
<xs:sequence> 
<xs: element name="x' 
<xs: element name="y' 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 
</xs :sequence> 

<xs: attribute name="unique-id" type="xs:ID' 
</xs : compl exType> 
<xs:element name="sites"> 
<xs : compl exType> 
<xs:sequence> 
<xs: element name="site" type="sites: siteType" minOccurs= 
maxOccurs="unbounded"/> 



type="xs : decimal "/> 
type="xs : deci mal "/> 



use="requi red"/> 



'0" 
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</xs:sequence> 
</xs : compl exType> 
</xs:element> 
</xs:schema> 

Le schema variant est obtenu par redefinition du type nomType du schema initial : 

<?xml version="1.0" encoding="UTF-8"?> 
<xs : schema xml ns : xs="http : //www. w3 . org/2001/XMLSchema" 
targetNamespace=" sites" 
xmlns :sites="sites"> 
<xs : redef i ne schemaLocati on="si tes . xsd"> 
<xs: compl exType name="nomType" mixed="true"> 
<xs:sequence m"inOccurs="l"> 

<xs:element name="prenom" type="xs :string"/> 
</xs:sequence> 
</xs : compl exType> 
</xs: redef ine> 
</xs: schema> 

Dans notre exemple, nous ne pourrions modifier que les definitions des types glo- 
baux. La creation d'une variante par cette technique peut done rendre obligatoire une 
revision du schema initial, ce que nous avons justement fait ici. 

La variante est obtenue par inclusion du schema initial et derivation de 
ses types 

Dans ce cas, la variante ne permet pas de modifier les definitions des elements du 
modele initial, mais seulement d'en ajouter. Les types globaux definis dans le modele 
initial peuvent quant a eux faire l'objet de derivation par restriction ou extension, 
conformement aux regies edictees par XML Schema. 

Dans l'exemple suivant, nous presentons le cas d'une variante creee par inclusion a 
partir d'un schema initial par inclusion. Dans cette variante, le type global nomType 
est derive pour donner le nouveau type newNomType. Toutefois, ce nouveau type ne 
peut etre substitue simplement au type associe a l'element nom. Ce dernier ayant ete 
defini globalement dans le premier schema, il ne peut pas faire l'objet d'une redefini- 
tion dans la variante (puisque nous operons une simple inclusion et non une redefini- 
tion du schema initial). Pour introduire le nouveau type, il faut creer un nouvel ele- 
ment ou utiliser l'attribut flottant xsi :type directement dans les documents XML. 
On doit se souvenir que XML Schema n'autorise la derivation que des types et non 
des elements. Le schema initial doit done etre ecrit en consequence et proposer une 
separation complete des definitions des types de celles des elements. 
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Dans la variante, la technique de l'inclusion ne donne pas le choix et l'introduction 
d'un nouveau nom d'element oblige tout simplement a recrire la definition de 1' ele- 
ment le contenant ! De proche en proche, c'est potentiellement la totalite du schema 
initial qu'il faut recrire. . . 

Le typage dynamique dans le corps des documents XML est la seule solution qui 
reste avec l'inclusion. Nous la donnons en exemple ci-apres. 

On voit que l'inclusion limite beaucoup les possibilites de creation de variantes. 

Le schema initial en est : 



<?xml version="1.0" encoding="UTF-8"?> 

<xs : schema xml ns : xs="http : //www. w3 . org/2001/XMLSchema"> 

<xs:complexType name="nomType" mixed="true"/> 

<xs: element name="nom" type="nomType"/> 

<xs:complexType name="photoType"> 

<xs: attribute name="nom" type="xs :anyURI" use="requi red"/> 
<xs: attribute name="format" type="xs:string"/> 
</xs : compl exType> 
<xs : compl exType name="si teType"> 
<xs:sequence> 
<xs: element ref="nom"/> 

<xs: element name="photo" type="photoType" minOccurs="0"/> 
<xs: element name="position"> 
<xs: compl exType> 
<xs:sequence> 
<xs: element name="x' 
<xs: element name="y' 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 
</xs:sequence> 

<xs: attribute name="unique-id 
</xs : compl exType> 
<xs:element name="sites"> 
<xs : compl exType> 
<xs:sequence> 
<xs: element name="site 
maxOccurs="unbounded"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 
</xs: schema> 



type="xs : deci mal "/> 
type="xs :decimal "/> 



type="xs : ID" use=" requi red"/> 



type="siteType" minOccurs="0" 
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II valide le document XML suivant : 

<si tes xml ns : xsi ="http : //www . w3 . org/2001/XMLSchema-i nstance" 

xsi :noNamespaceSchemaLocation="sites .xsd"> 
<site unique-id="ID000000"> 
<nom>Nicolas le Panda</nom> 
<photo nom=" photo.gif " format="gif"/> 
<position> 
<x>48.7494</x> 
<y>-2.1108</y> 
</position> 
</site> 
</sites> 

Le schema variant s'appuyant sur une inclusion du schema initial est le suivant : 

<?xml version="1.0" encoding="UTF-8"?> 
<xs : schema xml ns : xs="http : //www. w3 . org/2001/XMLSchema"> 
<xs : i ncl ude schemaLocati on="si tes . xsd"/> 
<xs:complexType name="newNomType" mixed="true"> 
<xs : compl exContent> 
<xs: extension base="nomType"> 
<xs: sequence minOccurs="l"> 

<xs: element name="prenom" type="xs: string"/> 
</xs:sequence> 
</xs:extension> 
</xs : compl exContent> 
</xs : compl exType> 
</xs: schema> 

II valide le document XML suivant, dans lequel on peut observer l'utilisation de 
l'attribut xsi :type : 

<si tes xml ns : xsi ="http : //www . w3 . org/2001/XMLSchema-i nstance" 

xsi : noNamespaceSchemaLocati on="si tesVari antelncl usi on . xsd"> 
<site unique-id="ID000000"> 

<nom xsi : type="newNomType"><prenom>Nicolas</prenom> le Panda</nom> 
<photo nom="photo.gif " format="gif"/> 
<position> 
<x>48.7494</x> 
<y>-2.1108</y> 
</position> 
</site> 
</sites> 
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Consequence de la creation d'une variante d'un 
sous-schema 



VOCABULAIRE Sous-schema 

Dans ce livre, nous appelons sous-schema un schema XML concu pour etre inclus dans un autre. On parle 
done de sous-schema comme on parlerait d'un sous-document. Cependant, il convient de noter que 
XML Schema ne definit aucunement la notion de « sous-schema », tout simplement parce qu'il ne s'y 
attache rien de specifique. Comme tout schema, un sous-schema doit etre valide independamment des 
schemas qui I'utilisent, ou que lui-meme utilise. 



La creation d'une variante d'un sous-schema peut avoir des consequences sur les 
schemas qui I'utilisent. 

Comme nous l'avons vu plus haut, la modification du sous-schema peut entrainer : 

• la creation d'un nouveau fichier contenant le nouveau sous-schema ; 

• la creation d'un nouvel espace de noms cible. 

Dans Fun ou l'autre de ces cas, les schemas principaux devront etre modifies. Si ces 
derniers sont eux-memes inclus dans d'autres, il se pourrait, par effet boule de neige, 
que nous soyons amenes a toucher un grand nombre de schemas. 

Un serieux probleme de conception de schema se pose alors potentiellement : en 
effet, pour eviter de prendre le risque de doubler toutes les definitions de tous les ele- 
ments et attributs, la seule solution consiste a creer un ou plusieurs catalogue(s) de 
types. Pour que cette conception des schemas soit coherente avec XML Schema, il 
faut imperativement que les types soient definis independamment des elements et 
des attributs, car XML Schema permet seulement de deriver des types et non des 
definitions d'elements ou d'attributs. 

Quand notre conception nous amene a creer une pyramide constitute de schemas et 
de sous-schemas, il faut commencer par creer les catalogues de types qui constitueront 
la base de cette pyramide. En clair, cela signifie que nous devons creer des schemas de 
bas niveau dans lesquels ne seront definis que des types, et plus nous irons vers le 
sommet de la pyramide et plus nos schemas definiront des structures complexes. 

Les schemas intermediates seront constitues des definitions d'attributs, des ele- 
ments simples et globaux. 

Cela revient finalement a parfaitement isoler les types des structures, ce qui rationa- 
lise enormement la programmation des schemas XML. 
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Consequence des variantes sur les liens 



Quand une structure de donnees XML est commune a plusieurs schemas, il est inte- 
ressant quelle soit directement associee a un document. Dans ce cas, le document 
contient des donnees parfaitement conformes a cette seule structure. On suppose que 
les donnees sont ainsi factorisees entre tous les documents XML utilisant cette struc- 
ture commune. 

Cela a ete fait dans l'application PiloteWeb qui sert de trame aux exemples de cet 
ouvrage. Les structures sites et partenaires sont partagees avec les autres selon 
l'organisation hierarchique des modeles que nous presentons a la figure 6-1. Atten- 
tion, la figure presente bien une hierarchie de dependances entre modeles et non une 
hierarchie d'elements XML ! 
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Une telle representation de la cascade des schemas utilises dans PiloteWeb, ou archi- 
tecture du modele, met en evidence non seulement l'interet des sous-schemas, mais 
egalement les dependances que cela engendre, notamment dans l'hypothese de crea- 
tion de variantes. 

Si une variante du modele pi 1 otes est creee, l'impact sera circonscrit au seul docu- 
ment XML correspondant, pilotes.xml. Si une variante de partenaires est creee, 
l'effet se fera sentir sur trois autres modeles : restaurants, loueurs et aeroclubs. 
Enfin, si une variante de si tes est creee, tous les modeles de PiloteWeb seront peut- 
etre concernes. 

Cela dit, nous avons choisi dans PiloteWeb de faire correspondre un document 
XML par schema du modele. Les donnees sont mises en commun grace a l'utilisa- 
tion de XLink dans les documents XML ; nous donnons ci-apres en exemple la rela- 
tion qui unit ainsi les donnees d'un site a celles de la structure pilote. 



Etapes de la demarche de modelisation 

Premiere partie 



Void un exemple de structure site : 

<?xml version="1.0" encoding="UTF-8"?> 

<si tes xml ns : xsi ="http : //www . w3 . org/2001/XMLSchema-i nstance" 

xsi : noNamespaceSchemaLocati on="si tes . xsd"> 
<s"ite unique-id="il5"> 
<nom>La bonne etoile</nom> 

<photo nom="labonneetoile.png" format="png"/> 
<position> 
<x>47.3105</x> 
<y>2.1566</y> 
</position> 
</site> 
</sites> 

Et void la structure pi 1 ote correspondante : 

<?xml version="1.0" encoding="UTF-8"?> 
<?xml version="1.0" encoding="UTF-8"?> 
<pi 1 otes xml ns : xsi ="http : //www . w3 . org/2001/XMLSchema-i nstance" 

xsi : noNamespaceSchemaLocati on="pi 1 otes . xsd"> 
<pilote unique-id="il9" publie="l"> 

<1ink x"link:type="simple" xlink: show="embed" xlink:href="sites.xml/ 
#xpoi titer (descendant: :site[@unique-id='il5'])"/> <- © 
<emai 1 >snai 1 @pi 1 oteweb . com</emai 1 > 
<pwd>secret</pwd> 
</pi"lote> 

Pour conserver i'independance des donnees (que Ton a voulu stocker dans des 
fichiers separes), nous avons utilise un element link porteur des attributs standards 
de la recommandation du W3C XLink. Les donnees de la structure site ad hoc sont 
virtuellement integrees (xlink:show="embed") a la structure pi Tote via le lien © qui 
reference l'identifiant (en l'occurrence la valeur i 15) de la structure si te souhaitee. 

Ainsi avons-nous modelise une hierarchie de modeles, mis en evidence les structures 
de donnees communes, tout en echappant au probleme des consequences de la crea- 
tion de variante. Avec la technique de modelisation que nous presentons ici, toute 
creation de variante a de fortes chances d'etre circonscrite a la seule variante. 
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En resume... 



Dans ce chapitre, nous avons vu, cas pratiques a l'appui, les differentes possibilites 
offertes pour creer et gerer des variantes. 

Nous avons egalement passe en revue les raisons qui pouvaient amener a la creation 
de variantes, ainsi que les consequences de ces creations. 

XML Schema est tres rigide dans les possibilites qu'il donne de creation de variantes. 
II se trouve que cela profite a la conception des architectures de modeles car l'expe- 
rience montre que la pyramide de schemas qu'impose XML Schema est salutaire. 
Elle permet tout a la fois d'obtenir des modeles generiques plus propres et d'avoir un 
meilleur controle des variantes. 

Enfin, nous avons vu que mettre en oeuvre XLink permettait de s'affranchir presque 
totalement des problemes de gestion des variantes. Grace a la solution que nous pre- 
sentons ici, les modeles ainsi que les documents XML restent independants les uns 
des autres. Les evolutions sont done prises en charge plus simplement. 

Apres avoir organise nos modeles sous la forme d'une pyramide de schemas, nous 
allons voir dans le chapitre suivant comment organiser les differentes couches de pro- 
grammation. 
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Nous allons traiter principalement de la place de XML dans les applications web, 
mais il ne faut pas croire pour autant qu'il n'a trait qua ce type d'applications ; toutes 
sont concernees par XML ! 

C'est en rationalisant les couches de traitement qu'on ameliore la qualite des pro- 
grammes. Cela concerne aussi bien les applications de commerce electronique que la 
production de documents ou encore l'integration d'applications. 

Comme dans le reste de cet ouvrage, nous ne nous interessons dans ce chapitre 
qu'aux seuls programmes de traitement relatifs a XML. 

Nous utilisons dans ce chapitre l'exemple de PiloteWeb, notre application web qui 
s'appuie sur XML de bout en bout : depuis le stockage des donnees dans une base de 
donnees XML jusqu'a l'affichage des pages dans le navigateur en passant par l'utilisa- 
tion de formulaires de saisie et un service web. Notre application repose sur un serveur 
de pages JSP, des API Java et l'utilisation de XQyery, Xpath, DOM, XLink et XSLT. 

Nous allons montrer comment le developpement d'une telle application doit faire 
alterner la modelisation des schemas XML de stockage avec la prise en compte des 
couches et langages de programmation. 
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Presentation generate 

Contrairement a ce que Ton imagine trop vite, une application web fondee sur XML 
ne se ramene pas a un probleme de transformation du XML en HTML au moyen de 
feuilles de style XSLT. La figure 7-1 schematise une telle approche. Ce n'est qu'une 
vue simpliste, et done fausse, d'une application web utilisant des donnees XML. 
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La figure 7-1 montre un fiot XML, produit par la conversion d'un format quel- 
conque ou fruit d'une requete XQuery aupres d'une base de donnees XML. Ces don- 
nees XML sont affichees dans un navigateur par transformation en HTML au 
moyen d'une feuille de styles XSLT. Un tel schema ne fonctionne pas, car il presente 
les inconvenients suivants : 

• II n'autorise, au maximum, que deux etapes de transformation des donnees 
XML : au moment de l'execution de la requete XQuery et au moment de la trans- 
formation en HTML par XSLT. C'est insuffisant. 

• II ne tient pas compte du role du serveur web et de son architecture propre. 

• II ne represente pas la partie transactionnelle des acces a la base de donnees ni le 
dialogue provoquant l'execution des requetes XQuery. 

• II ne dit rien quant a la gestion des messages d'erreur. 

• II ne permet pas de tenir compte des transformations qui seraient conditionnees 
par des contraintes externes, pourtant souvent necessaires. 
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C'est la prise en compte de ces points qui rend si difficile la conception des applica- 
tions, dont la realite meme est bien complexe et malaisee a exposer et representer 
visuellement. Cela est probablement d'autant plus vrai que les applications d'Internet 
sont si nombreuses que n'importe quelle representation ou tentative de modelisation 
pourrait etre discutee pendant des heures. Afin de cerner notre propos, nous nous 
basons sur un cas d'ecole simple et didactique, mais dont nous pensons qu'il peut 
toutefois servir de modele a des cas plus sophistiques. 

La force du modele que nous presentons reside dans sa coherence avec la methode 
d'analyse presentee a l'etape 1 : cette derniere aura permis d'identifier les differentes 
etapes de fabrication de l'information. Le modele en resultant peut servir de base de 
travail pour le decoupage logique des traitements. 

Dans une application web, on ne voit du monde des documents que des pages 
HTML qui peuvent elles-memes contenir des programmes executes au moment de 
l'affichage. On ne peut plus des lors se contenter de representer les documents struc- 
tures sous la forme du classique triptyque fond, forme, structure, comme le montre la 
figure 7-2. II faut lui aj outer un quatrieme volet, celui des programmes applicatifs 
embarques dans le document, ce que nous representons par un losange a la figure 7-3. 

Figure 7-2 
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Figure 7-3 
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La figure 7-1 est erronee precisement parce que cette dimension specifique aux docu- 
ments web est absente. Nous devons y ajouter les elements qui traduisent les capacites 
d'integration : au minimum, il s'agit d'un serveur d'application web, d'un langage de 
gestion des requetes XQuery, et enfin d'un langage de generation de pages. 

Un meilleur modele de base pour notre conception d'application est celui represente 
a la figure 7-4. 
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Figure 7-4 Representation plus exacte d'une architecture logique applicative 



La seule intelligence applicative qu'on puisse ajouter dans un document 
« simplement » HTML se ramene a des programmes embarques dans le code, tel du 
JavaScript. Avec des documents XML embarquant une logique applicative via leurs 
balises, on passe par des appels de pages dont l'execution produit des documents 
XML qui, apres conversion par XSLT, produisent des documents HTML qui, a leur 
tour, peuvent contenir des programmes executes au moment de l'affichage. 
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C'est ce dernier cycle de traitements que represente la figure 7-4. Partons d'une 
requete emise depuis un visualiseur HTML et suivons le parcours de cette requete 
jusqu'a 1'affichage de la reponse qu'elle provoque : 

1 La requete est recue par un serveur d'applications web (service des processus 
d'interfaces) ; elle consiste en une demande d'activation de page. Le serveur 
d'applications web decortique la page appelee. 

2 II execute, via les arguments de la requete, le programme demande (service des pro- 
cessus metier) dont l'appel est code dans la page. 

3 Ce programme peut executer un simple calcul ou etre lui-meme l'auteur d'une 
requete vers un referentiel metier (une base de donnees par exemple). 

4 Ce dernier service va finalement executer la requete physique qui consiste a recu- 
perer les donnees demandees et les retourner au programme appelant. 

5 Le programme appelant (le service des processus metier) va transmettre les don- 
nees au service de processus d'interfaces apres les avoir eventuellement transforme 
les donnees. Cet envoi peut etre un flot de donnees XML ou HTML. 

6 Enfin, le service des processus d'interfaces va convertir les donnees en HTML 
definitif a des fins d'affichage dans le visualiseur d'ou est partie la requete initiale. 

Dans J2EE, le langage de generation de pages est JSP. Nous l'utilisons pour ecrire les 
squelettes de pages web. Le langage correspondant au serveur de processus metier est 
Java sous la forme d'un bean. La technique des beans Java, reconnue des serveurs 
d'application J2EE, permet en particulier de garantir le partage et la persistance des 
donnees sur le serveur entre plusieurs appels de pages JSP. Enfin, quand on dispose 
d'une base de donnees XML, le langage de requete utilise par le service du referentiel 
metier est XQuery 

Le graphique de la figure 7-5 met en evidence l'ensemble des langages utilises depuis 
l'appel initial d'une page JSP jusqu'a 1'affichage de la reponse sous la forme d'une 
page HTML. Nous allons continuer a etudier ces langages et la maniere dont ils 
peuvent s'imbriquer les uns dans les autres. La figure 7-6 donne enfin une represen- 
tation epuree de l'enchainement des langages : dans cette representation, toute autre 
notion a ete retiree. 

On trouve a l'extreme gauche de la figure 7-6 les donnees XML stockees, souvent 
selon un schema specifique au stockage, et a l'extreme droite les pages HTML affi- 
chees. Si le role des schemas XML est important dans la partie gauche, on ne peut 
pas en dire autant des pages affichees. HTML est un langage de presentation qui ne 
traite que de la mise en forme des donnees, toute notion de structure ayant done dis- 
paru des donnees. 
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La figure 7-6 est plus apte a nous faire reflechir sur la rationalisation des differentes 
couches de programmation que les figures 7-1 et 7-4, car elle met en evidence les 
problemes de modelisation orientee metier (a gauche) et orientee presentation (a 
droite). Les langages et les etapes de transformation ne sont alors qu'autant de pro- 
cessus visant a transformer un contenu structure (l'information brute metier) en une 
forme lisible (information raffinee consommable). Cette maniere de voir les choses 
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est interessante pour la modelisation globale du systeme. Dans la section suivante, 
nous montrons comment cette representation de l'architecture du systeme amene 
une meilleure methode de conception et d'analyse des modeles XML du systeme. 



D'un modele de stockage a un modele de presentation 

Les transformations dont nous avons parle jusqu'a maintenant ne sont que la partie 
visible d'un probleme methodologique : comment definir avec certitude et a l'avance 
(des les phases de conception) quelle partie de la programmation prendra en charge 
telle partie des traitements ? 

Si Ton accepte l'idee que les donnees passent par six etats differents et pas moins de 
quatre types de transformations avant d'etre affichees dans un quelconque naviga- 
teur, alors les questions relatives a la rationalisation des traitements sont les 
suivantes : 

• Quel langage utiliser pour un type donne de transformation ? 

• A quel stade une transformation doit-elle etre faite ? 

• Comment ecrire les specifications correspondantes ? 

• Comment rendre generiques, communs, les programmes de transformation ? 

Repondre a ces questions est d'autant plus malaise que les transformations elemen- 
taires sont nombreuses. II est alors difficile de toutes les modeliser et documenter. 

Pour y parvenir toutefois, nous allons scinder le probleme en deux volets distincts et 
considerer : 

1 d'une part, que toute transformation n'a comme seul objectif que de faire passer 
les donnees d'un modele A a un modele B ; 

2 d'autre part, que les langages imposent plus ou moins d'eux-memes l'ordre des 
operations de transformation. 

Ces deux points seront detailles dans les deux prochaines sections. 

Organisation du modele de stockage 

Pour illustrer ce point, nous allons utiliser comme exemple Fun des cas traites dans 
notre application ecole PiloteWeb : le traitement des coordonnees geophysiques 
(latitude/longitude) des aerodromes, pilotes et partenaires (restaurants, loueurs de 
voitures...). En effet, PiloteWeb calcule, pour chaque aerodrome affiche, les pilotes 
et prestataires de services proches de l'aerodrome en question. Cela se fait par com- 
paraison de leurs positions geographiques respectives. 
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L'application PiloteWeb est conforme au schema presente plus haut a la figure 7-5. 
Les donnees sont exprimees en XML d'un bout a l'autre de l'application et ne sont 
transformees en HTML qu'au tout dernier moment. Cette derniere transformation 
est assuree par une feuille de styles XSLT, tandis que toutes les autres sont calculees 
par des programmes Java ou JSP. 

Dans la base XML utilisee, les donnees sont organisees autour de sept schemas et 
dependent les unes des autres conformement a la figure 7-7. 
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Comme nous l'avons explique lors de l'etape 6, ce modele hierarchique de 
schemas XML exprime le fait que certaines donnees sont partagees par plusieurs 
objets. C'est ainsi que le schema XML sites contient la structure qui permet 
d'exprimer la position geographique de n'importe quel objet de la base : pilotes, 
aerodromes, partenai res, restaurants, loueurs et aeroclubs. Les trois derniers 
(restaurants, loueurs et aeroclubs) ont eux-memes une structure en commun 
exprimee par le schema XML partenai res, qui decrit les informations pratiques 
communes a tous les partenaires : nom, numero de telephone, disponibilite, etc. 

Lorganisation presentee a la figure 7-7 montre les relations de dependance entre les 
schemas XML : ceux du bas heritent de ceux du haut. 

Les donnees sont stockees dans autant de documents XML qu'il y a de schemas dans 
cette organisation hierarchique, soit sept au total. II faut done noter ici la tres grande 
difference qu'il y a entre stocker toutes les donnees d'un meme objet dans un seul 
document XML et les repartir dans plusieurs documents XML differents (comme 
c'est le cas ici). Par exemple, les donnees descriptives d'un loueur de voiture sont, 
dans notre cas d'ecole, stockees dans trois documents XML : l'un stocke la position 
geographique, l'autre les informations pratiques et le dernier les donnees specifiques. 
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Pour obtenir la totalite des informations relatives a un loueur de voiture en particu- 
lier, rapplication devra faire la jointure de ces trois documents XML. 

Le modele sites est commun a tous les autres. Les schemas pilotes et aerodromes 
heritent de ce modele, qu'ils completent par leurs propres structures XML car les 
pilotes et les aerodromes ont chacun des caracteristiques specifiques. Aucun autre 
schema n'herite de ces deux modeles : ils sont terminaux. II n'en va pas de meme 
pour partenai re qui, comme nous l'avons vu, sert de base a trois autres modeles de 
PiloteWeb : restaurants, loueurs etaeroclubs. 

Nous allons etudier deux de ces schemas dans la suite de ce chapitre et montrer des 
exemples valides des documents XML correspondants. 

Schemas sites et pilotes 

Tous les objets que notre application manipule ont en commun un reperage geogra- 
phique, compose d'un nom, d'une position geographique et d'une photo optionnelle. 
Ces donnees font l'objet du schema si te. 

Lelement racine est sites (au pluriel). II contient autant d'elements site (au singu- 
lier) que d'objets introduits dans la base. En voici le schema : 

<?xml version="1.0" encoding="UTF-8"?> 
<xs : schema xml ns : xs="http : //www . w3 . org/2001/XMLSchema" 
xmlns :xsi=" http://www.w3 . org/2001/XMLSchema- instance" 
target Names pace=" sites" 
xmlns: si tes=" sites"> 
<xs: element name="nom" type="xs:string"/> 
<xs : compl exType name="photoType"> 
<xs: attribute name="nom" type="xs :anyURI" use="requi red"/> 
<xs: attribute name="format" type="xs:string"/> 
</xs : compl exType> 

<xs : compl exType name="posi ti onType"> 
<xs:sequence> 
<xs: element ref="sites:x"/> 
<xs: element ref="sites:y"/> 
</xs:sequence> 
</xs : compl exType> 
<xs : compl exType name="si teType"> 
<xs:sequence> 
<xs: element ref="sites: nom"/> 

<xs: element name="photo" type="sites: photoType" minOccurs="0"/> 
<xs:element name="position" type="sites :positionType"/> 
</xs:sequence> 

<xs: attribute name="unique-id" type="xs:ID" use="requi red"/> 
</xs : compl exType> 
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<xs:element name="sites"> 
<xs : compl exType> 
<xs:sequence> 
<xs:element name="site" type="sites:siteType" 

mi nOccurs="0" maxOccurs="unbounded"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 

<xs:element name="x" type="xs :decimaV'/> 
<xs:element name="y" type="xs :decimaV'/> 
</xs:schema> 

L'attribut unique-id de 1' element entite identifie chaque element site de maniere 
unique afin d'y faire reference a partir des instances des modeles enfants. 

Un document XML conforme a ce schema se codifie ainsi : 

<?xml version="1.0" encoding="UTF-8"?> 

<sites: sites xmlns :xsi=" http://www.w3 . org/2001/XMLSchema- in stance" 
xsi :schemaLocation="sites sites. xsd" xmlns: sites="sites"> 
<sites:site unique-id="il"> 
<nom>Pilote de Demo</nom> 
<photo nom="pingouin . jpg" format="jpg"/> 
<position> 

<x>48.7494</x> 
<y>-2.1108</y> 
</position> 
</sites:site> 

<sites:site unique-id="i2"> 
<nom>Nicolas le Panda</nom> 
<photo nom="merlin.gif" format="gif"/> 
<position> 

<x>47.9505</x> 
<y>-0.19</y> 
</position> 
</sites:site> 

<sites:site unique-id="i3"> 
<nom>Max</nom> 

<photo nom="max.gif " format="gif"/> 
<position> 

<x>47.9347</x> 
<y>-0.2172</y> 
</position> 
</sites> 
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S'agissant du schema pi Totes, etudions tout d'abord l'instance XML des pilotes : 

<?xml version="1.0" encoding="UTF-8"?> 

<pn 1 otes : pi 1 otes xml ns : pi 1 otes="www . pi 1 oteWeb . xml /pi 1 otes" 
xml ns : xl i nk="http : //www . w3 . org/1999/xl ink" 
xml ns : xsi ="http : //www. w3 . org/2001/XMLSchema-i n stance" 
xsi :schemaLocation="www. pi 1 oteWeb. xml /pi Totes pi"lotes.xsd"> 
<pilote unique-id="il6" publie="l"> 

<link xlink: type="simple" xlink:show="embed" 
xlink: href=" sites .xml/#xpointer( 

descendant: : site[@unique-id='il'])"/> <- © 
<emai 1 >pi 1 oteOpi 1 oteweb . com</emai 1 > 
<pwd>avi on</pwd> 
</pilote> 
<pilote unique-id="il7" publie="l"> 

<link xlink: type="simple" xlink:show="embed" 
xl i nk : href="si tes . xml /#xpoi nter( 

descendant: : site[@unique-id='i2 '])"/> <- © 
<emai 1 >panda@pi 1 oteweb . com</emai 1 > 
<pwd>secret</pwd> 
</pilote> 
</pi lotes : pi lotes> 

Les pilotes sont caracterises par un nom, une photo et une position geographique, 
donnees communes a tout objet gere par PiloteWeb. Ces dernieres sont ici referen- 
cees par le biais d'un lien vers le document XML sites (repere ©). Les pilotes ont en 
propre une adresse electro nique (element emai l) et un mot de passe (element pwd). 

Void le schema correspondant : 

<?xml version="1.0" encoding="iso-8859-l"?> 
<xs : schema xml ns : xs="http : //www. w3 . org/2001/XMLSchema"> 
<xs : compl exType name="pi 1 oteType"> 
<xs:sequence> 
<xs: element name="link"> 
<xs : compl exType> 
<xs : anyAttri bute namespace="http : //www . w3 . org/1999/xl ink" 
processContents="strict"/> 
</xs : compl exType> 
</xs:element> 

<xs: element name="email" type="emailType" nillable="false"/> 
<xs: element name="pwd" type="xs:NCName" nillable="false"/> 
</xs:sequence> 

<xs: attribute name="unique-id" type="xs:ID"/> 
<xs: attribute name="publie" type="xs: boolean" default="l"/> 
</xs : compl exType> 
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<xs : si mpl eType name="emai lType"> 
<xs: restriction base="xs:string"> 

<xs : pattern val ue=" (\c)*@(\c) '••"/> 
</xs : restrict! on> 
</xs : si mpl eType> 

<xs:element name="pilote" type="piloteType"/> 
<xs:element name="pilotes"> 
<xs : compl exType> 
<xs:sequence> 

<xs:element ref="pilote" maxOccurs="unbounded"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 
</xs:schema> 

L'organisation des schemas presentee a la figure 7-7 se traduit par la mise en ceuvre 
de liens XLink. Comme nous l'avons precise a l'etape 6, nous recommandons l'usage 
de XLink pour minimiser les efforts de migration lors d'une eventuelle evolution des 
modeles. 

Les modeles sont ici suffisants pour comprendre la nature des donnees exprimees. 
Leur seule lecture apporte deja beaucoup d'informations sur le type d'application, et 
ce meme si la totalite de la semantique n'est pas exprimee dans le schema (telles les 
regies syntaxiques etla signification exacte de l'adresse email). 

Par contraste, nous allons observer les modeles utilises au niveau de l'affichage de ces 
donnees. II s'agit des DTD dites d'affichage. 



Remarque Utilisation des DTD et des schemas 

Dans ce chapitre, nous utilisons les schemas XML pour les modeles de stockage et les DTD pour les 
modeles d'affichage. Cela montre d'une part que les deux peuvent cohabiter au sein d'une meme appli- 
cation, et d'autre part que le passage de I'un a I'autre sera probablement chose courante dans la docu- 
mentation des applications de XML. En effet, I'ecriture des modeles XML sous la forme de DTD est beau- 
coup plus concise et simple a lire que sous la forme de schemas XML, ce que nous avons mis a profit ici. 



Organisation des modeles d'affichage 

Les DTD dont nous allons parler dans cette section sont celles utilisees juste avant 
conversion en HTML des donnees XML ; la DTD finale HTML n'ayant, quant a 
elle, rien de particulier, sinon son caractere tres generaliste que tout un chacun connait. 

Les DTD d'affichage representent la somme de toutes les donnees accumulees au 
cours des differentes etapes de traitement : on va done y retrouver les modeles des 
donnees extraites de la base et conservees jusqu'a l'affichage, de celles produites par 



Etape 7 - Organiser les differentes couches de programmation 

Chapitre 7 



l'execution des pages JSP, recues de services web (ce qui est le cas dans PiloteWeb), et 
enfin resultant des calculs faits en Java. 

La figure 7-8 rend compte de l'organisation des DTD utilisees dans le service des 
processus d'interfaces de notre application. 
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Les modeles d'affichage sont divises en deux mondes. Lun est constitue de modeles 
generiques independants les uns des autres (base.dtd, aerodrome. dtd et 
formulaire.dtd), l'autre renferme des modeles s'appuyant sur des combinaisons de 
ces modeles generiques. 

II y a le plus souvent autant de DTD d'affichage que de modeles de pages web a affi- 
cher, chaque page web etant la somme de plusieurs de ces DTD (par exemple, un par 
cadre de page web). Comme pour les schemas XML de stockage, ces DTD sont en 
partie dependantes les unes des autres. Les modeles communs correspondent alors ici 
aux mises en page types communes a plusieurs pages web (par exemple, un cadre uti- 
lise a l'identique dans plusieurs pages web). 

Dans le cas de notre application ecole, nous n'allons etudier que la DTD d'affichage 
formulai res .dtd : 

<! ENTITY % principal (p* , formulai re?)> 

<! ENTITY % base SYSTEM "base.dtd"> 

<! ENTITY % formulai res SYSTEM "formulai res. dtd"> 

%base; 

%formulai res; 

Elle est la combinaison de deux DTD de base, base . dtd et f ormul ai res . dtd. 
Void la DTD base . dtd : 



<! ENTITY % principal "EMPTY"> 

<! ENTITY % page 

"((quitter, raccourcis , principal) | (login, raccourcis, principal))"> 
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ELEMENT page %page;> 

ELEMENT quitter EMPTY> 

ELEMENT login EMPTY> 

ELEMENT raccourcis (a*)> 

ELEMENT a (#PCDATA)> 

ATTLIST a href CDATA #REQUIRED> 

ELEMENT principal %principal;> 

ATTLIST principal titre CDATA #REQUIRED> 



Et la DTD formulai res.dtd : 



ELEMENT formulai re (liste | choixl textel passe | position |fichier)*> 

ELEMENT liste (option+)> 

ELEMENT option (#PCDATA)> 

ELEMENT choix EMPTY> 

ELEMENT texte EMPTY> 

ELEMENT passe EMPTY> 

..Suivi d'une liste de definition d'attributs. 



La lecture de ces DTD montre immediatement que le balisage semantique des 
schemas XML de stockage a laisse la place a un balisage de composition sans pour- 
tant etre deja le balisage HTML final (trop independant de toute application). Ce 
modele est specifique a notre application dont il traduit la coherence des presenta- 
tions des pages web. 

En particulier, on y trouve les elements login, quitter et principal qui correspon- 
dent aux ecrans de connexion a 1' application, sortie et menus principaux. On com- 
prend mieux ici pourquoi ces elements n'ont rien a faire dans la base de donnees mais 
font partie du dialogue de 1' application : ils doivent etre introduits dans le flot des 
donnees a une certaine etape des traitements. 



En synthese 



Dans cette section, nous avons mis en evidence l'existence de modeles qui ont pour 
vocation d'assurer, d'un cote le partage des donnees entre le plus grand nombre d'appli- 
cations possibles, et de 1' autre la coherence des pages web d'une application donnee. 

La transformation des donnees d'un modele a un autre doit done etre etudiee comme 
etant la somme de micro-transformations permettant de passer d'un modele metier 
(stockage des donnees) a un modele applicatif (le modele d'affichage), chacun d'eux 
etant en fait compose d'un ensemble de DTD organisees comme nous 1' avons vu aux 
figures 7-7 et 7-8. Ces DTD doivent bien sur etre en coherence avec 1' architecture 
de l'application qui les gouverne. 
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Les differentes couches de programmation 

Dans cette section, nous presentons les langages utilises pour faire evoluer les donnees 
d'un modele metier a un modele de restitution, d'affichage et de dialogue interactif 
avec l'utilisateur. Nous allons voir que chaque langage ayant ses propres specifications, 
toute transformation n'est pas systematiquement possible a l'endroit souhaite. 

Les cinq langages de programmation utilises dans PiloteWeb correspondent a cinq 
couches qui, selon la theorie, sont les suivantes : 

• la mise en correspondance fonctionnelle, ou mapping, realisee en XQuery ; 

• la programmation en Java des objets d'entreprise ; 

• la programmation des objets metier en JSP ; 

• la programmation de la presentation en XSLT ; 

• la programmation de l'affichage avec HTML. 

Le schema 7-9 rappelle ici ceux des figures 7-5 et 7-6 du debut du chapitre. II cor- 
respond a la chaine logique des traitements, que Ton peut resumer ainsi : Stoc- 
kage<— >Referentiel Entreprise<— >Processus Metier<— >Processus IHM. 
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Chaque couche fait l'objet d'une description plus precise dans les sections qui suivent. 



Mise en correspondance fonctionnelle avec XQuery 

Cette couche a pour mission d'apporter les donnees a tout programme des couches 
superieures, principalement les programmes des couches entreprise et metier. 

Lutilisation de requetes XQuery peut etre en effet rendue necessaire pour trans- 
former des donnees destinees tant a i'ensemble de l'entreprise qua une application en 
particulier ; il s'agit alors d'objets metier. 

Par exemple, dans PiloteWeb, les positions geographiques des objets sont saisies et 
affichees sous la forme degre, minute, seconde (unite que Ton notera dms dans la 
suite de cette section). Nous avons pourtant choisi de les stocker sous la forme deci- 
male, car le type decimal existe en XML Schema, alors qu'il n'existe pas de type dms. 
Cela entraine des conversions systematiques de ces donnees lors de toute operation 
de stockage/destockage. 
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Les figures 7-10 et 7-11 montrent la maniere dont les positions geographiques des 
objets sont presentees aux utilisateurs de l'application, tandis que la figure 7-12 
explique comment ces memes donnees sont stockees dans la base. 
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La lecture des nombres x et y stockes sous forme decimale dans la base fait l'objet 
d'un programme XQuery particulier. Leur conversion en dms ne peut etre effectuee 
que par un programme Java acceptant comme argument d'entree une chaine de 
caracteres de type decimal et retournant en sortie sa correspondance en dms. Ce pro- 
gramme n'est pas specifique a l'application PiloteWeb. C'est un programme gene- 
rique qui pourrait etre utilise par plusieurs applications differentes, un programme de 
type entreprise. 



Aparte DMS 

Acronyme representant I'unite degre-minute-seconde. 



Voici le code source de la requete XQuery qui retourne la position X d'un objet dont 
nous connaissons l'identifiant i d (dans notre exemple, on a donne a l'identifiant la 
valeur 16) : 

for $i in document('/P"NoteWeb-data/')//" : * [@unique-id="il6"] <- © 
let $a := '/piloteWeb-data/' , <- O 

$b := substring-before(string($i/*:~link/@*:href) , '/') , 

$c := concat($a,$b), 

$d := substring-after(string($i/*:"link/@' v :href) , "unique-id=' ") , 

$e :=substring-before($d, " ' ") 
for $obj in document($c)//* [@unique-id=$e] 

return <return>{$obj/position/x/text()}</return> <- © 

Cette requete ne va pas chercher directement la valeur X correspondant a l'objet i 16 
car, dans PiloteWeb, les coordonnees (x , y) d'un objet sont stockees dans un docu- 
ment XML distinct de l'objet lui-meme. La requete XQuery recherche done l'objet 
dont on connait l'identifiant (repere ©), puis decortique le lien qui relie cet objet au 
document XML contenant les coordonnees (x , y) . C'est le but de la serie des ordres 
1 et qui commence au repere O. Enfin, ce programme retourne la coordonnee X 
trouvee (repere ©). 

La liste deroulante des aerodromes utilisee dans les pages web de l'application est 
pour partie indissociable du code des pages en question. Ces programmes se trouvent 
dans la couche metier. Le calcul de l'affichage de cette liste se divise en deux niveaux 
de programmation; l'un du niveau metier, 1' autre du niveau mise en correspondance : 

• niveau metier : le code JSP qui recupere cette liste et la transforme en menu 
deroulant ; 

• niveau entreprise : le programme Java qui recupere la liste d'aerodromes retournee 
par la requete XQuery sous forme de DOM ; 

• niveau mise en correspondance : la requete XQuery qui ramene la liste des aero- 
dromes. 
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La requete XQuery utilisee est la suivante : 

for $i in document('/piloteWeb-data/')/* : aerodromes/*: aerodrome <- © 
let $unique-id := $i/@unique-id, <- O 
$a := '/piloteWeb-data/' , 

$b := substring-before(string($i/*:link/@*:href) , '/') , 
$c := concat($a,$b) , 
$d := substring-after(string($i/* :link/@* :href) , 

"unique-id=' ") , 
$e :=substring-before($d, " ' ") 

for $obj in document($c)//* [@unique-id=$e] <- © 
return <returnxintitule>{$i/* : code/text ()} , 
{$obj/nom/text()}</intitulexaerod romei d> 
{string($unique-id)}</aerodromeid> 
<siteid>{$e}</siteidx/return> <- © 

Cette requete va chercher tous les aerodromes declares dans la base de donnees 
(repere ©). Pour chacun, elle decortique le lien qui s'y trouve (serie des let du 
repere O) et va chercher les morceaux d'information complementaires dans les docu- 
ments XML pointes par chaque structure aerodrome (repere ©). Ces informations 
etant collectees dans les variables $i et $obj, la requete les combine sous la forme 
d'une nouvelle structure XML (repere ©) qui donne le resultat suivant : 

<return> 

<intitule>LFRM, Le Mans, Arnage</intitule> 

<ae rod romei d>i 2 l</ae rod romei d> 

<si tei d>i 6</si tei d> 
</return> 
<return> 

<intitule>LFRS, Nantes, Atlantique</intitule> 

<ae rod romei d>i 2 2 </ae rod romei d> 

<si tei d>i 7</si tei d> 
</return> 
<return> 

<intitule>LFRZ, Saint Nazaire, Montoi r</intitule> 

<ae rod romei d>i 2 3</ae rod romei d> 

<si tei d>i 8</si tei d> 
</return> 
<return> 

<intitule>LFPN, Toussus, le Noble</intitule> 

<ae rod romei d>i 24</ae rod romei d> 

<si tei d>i 9</si tei d> 
</return> 
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Programmes du niveau entreprise (Java) 

Les programmes de cette couche recoivent les donnees XML retournees par les 
requetes XQuery et les rendent exploitables pour des calculs generiques de transfor- 
mation avant d'etre remises aux programmes de la couche metier. 

Nous avons vu que c'est typiquement le cas pour les coordonnees (x , y) des objets. 

Void le programme Java qui execute la requete XQuery etudiee a la section 
precedents : 



+ Db + " ')/* :aerodromes/ 



public Iterator searchXFromId(String id) { 
String theQuery = "for $i in document(" 
*:aerodrome[@unique-id=' " + id + "'] \n" + 
"let $a := '" + Db + " ' , \n" + 

$b := substring-before(string($i/* :link/@* :href) , '/') , \n" + 
" $c := concat($a, $b) , \n" + 

$d := substring-after(string($i/*:link/@*: href) , 
\"unique-id='\") , \n" + 
" $e :=substring-before($d,\" '\") \n" + 

for $obj in document($c)//*[@unique-id=$e] \n" + 
return <return>{$obj/position/x/text()}</return>" ; 
if (dblsConnectedO) { 

Iterator result = myExecuteQuery(theQuery) ; <- © 
return result; 
} else { 

return null ; 
} 
} 

On remarquera d'une part le changement syntaxique de la requete XQuery, lie a son 
utilisation dans un programme Java, et d'autre part la mise sous forme de 
variable (Db) du nom de la base XML et de l'identifiant de l'objet recherche 
(variable id). Le programme est ainsi rendu generique et peut etre utilise par plu- 
sieurs applications et bases de donnees differentes. Lexecution a proprement parler 
de la requete est confiee au programme myExecuteQuery (repere ©) dont la descrip- 
tion ha pas d'interet ici. 

Ce programme est accompagne des codes de transformation des coordonnees (x , y) 
en dms : 



public String getDecodedXFromld (String id) { 
float Xf = getFloatXFromld(id) ; 
int Xdegre = (int) (Xf - (Xf % 1)); <- ® 
String X = String. valueOf (Xdegre) + "'"; 
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float Xmf = ((Xf - Xdegre) % 1) * 60 - ((((Xf-Xdegre) % 1)*60) %1) ; <- ® 

int Xminute = (int) Xmf; 

X = X + String. valueOf (Xminute) + "'"; 

int Xseconde = (int) ((Xf - Xdegre - (((float) Xminute) / 60.0)) 

* 3600); <r <D 
X = X + String. valueOf (Xseconde) + """; 
return X; 
} 

public float getFloatXFromld (String id) { 
Iterator result = searchXFromld(id) ; 

String X = getLitteralValueFromSimplelterator(result) ; <- © 
float Xf; 
if (X != "") { 

Xf = Float. parseFloat(X); <r © 
} else { 

Xf = 0; 
} 

return Xf; 
} 

Ces programmes (ici ceux pour le decodage de X - les memes existent pour Y) recu- 
perent une valeur X sous forme de chaine de caracteres a l'interieur du DOM (Docu- 
ment Object Model) retourne par la requete XQuery (repere ©), la convertissent en 
nombre flottant (repere ©), puis operent la transformation en dms (repere ®). 

Bien qu'il s'agisse d'une transformation, on se rend compte ici que la nature de cette 
transformation n'a aucun rapport avec ce que propose le langage XSLT : d'une part, 
de tels calculs numeriques sont impossibles en XSLT et, d'autre part, leurs resultats 
doivent pouvoir etre utilises par d'autres programmes Java. 

En ce qui concerne la liste des aerodromes, la requete XQuery presentee a la section 
precedente fait l'objet des differents programmes en action. 

Void un programme d'execution de la requete : 

public Iterator searchlntitulesAerodromesO { 

String theQuery = "for $i in documentC" + piloteWebDb + "') 
/*: aerodromes/* :aerodrome \n" + 
'let $unique-id := $i/@unique-id, \n" + 
$a := "' + piloteWebDb + '", \n" + 

$b := substring-before(string($i/'- :link/@' v :href) , '/') > \n" + 
1 $c := concat($a, $b) , \n" + 

$d := substring-after(string($i/*:link/@*: href) , 

\"unique-id='\") , \n" + 
$e :=substring-before($d,\" '\") \n" + 
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} 



for $x in document($c)//*[@unique-id=$e] \n" + 
" return <return> 

<intitule>{$i/* : code/text ()} , {$x/nom/text()}</intitule> 
<aerodromeid>{string($unique-id)}</aerodromeid> 
<siteid>{$e}</siteid> 
</return>" ; 
if (dblsConnectedO) { 

Iterator result = myExecuteQuery(theQuery) ; 
return result; 
} else { 

return null ; 
} 



Un programme de decorticage des donnees retournees (repere ©) sous forme de 
DOM : 



public boolean creerListeDesIntitulesAerodromesO { 
Vector aTemp = new VectorO; 
Vector bTemp = new VectorO; 
Vector cTemp = new VectorO; 

Iterator result = searchlntitulesAerodromesO ; <- © 
if (result != null) { 

while (result. hasNextO) { 

XQueryValuelf value = (XQueryValuelf) result. next() ; 
NodeList subtree = value. asNode() .getChildNodes() ; 
aTemp. add El ement(subtree.i tern (0) .getChildNodes() . item(0) .getNo 
deValueO); 

bTemp. add El ement(subtree.i tern (1) .getChildNodes() . item(0) .getNo 
deValueO); 

cTemp. add Element (subtree. item (2) .getChildNodes() . item(0) .getNo 
deValueO); 
} 
} 

listeDesAerodromes = new St ring [aTemp. si ze() ] ; <- © 
listeDesIDAerodromes = new String[bTemp. size()] ; <- © 
listeDesIDSitesAerodromes = new String[cTemp.size()] ; <- © 
aTemp. copylnto(listeDesAerodromes) ; 
bTemp. copylnto(listeDesIDAerodromes) ; 
cTemp.copylnto(listeDesIDSitesAerodromes) ; 
return true; 
} 

On obtient trois variables (reperes © © ©) : les listes des noms et des identifiants 
primaires et secondaires des aerodromes. 
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On voit que ces programmes realisent des traitements generaux independants de 
toute application specifique (dite metier). 

Programmes du niveau metier (JSP) 

Ces programmes utilisent les variables calculees dans la couche precedente pour les 
associer et les assembler entre elles, et leur donner ainsi une logique applicative, que 
Ton appelle metier. 

Par exemple, pour l'affichage des positions geographiques des objets, la forme JSP 
utilisee est la suivante : 

oerodrome code="<%= pi"loteWeb.getCodeAerodromeFromId(idAerodrome) %>" 
nom="<%= nomAerodrome %>" 

photo="<%= pi ~l oteWeb. getPhotoFromSiteld(idAerodrome) %>" 
x="<%= pi"loteWeb.getDecodedXFromId(idAerodrome) %>" 
y="<%= pi"loteWeb.getDecodedYFromId(idAerodrome) %>"> 

Une fois executee par le serveur Web, la page JSP produit un element XML, tel que : 

<aerodrome code="LFRM" nom="Le Mans, Arnage" photo="lemans. jpg" 
x="47 ° 56 ' 54&quot ; " y="0 ' 12 ' 5&quot ; "> 

Les valeurs x et y sont recuperees du programme Java de la couche precedente grace 
aux fonctions getDecodedXFromld(idAerodrome) et getDecodedYFromld(idAerodrome) 
appliquees a la bean Java reconnue des pages JSP sous le nom pi ^ oteWeb . 

C'est ainsi que les donnees sont transmises de la couche entreprise a la couche metier. 

Quant a la liste des aerodromes requise pour la fabrication de la liste deroulante illus- 
tree a la figure 7-13, voici sa programmation en JSP : 

<% if ((pi"loteWeb.getAerodromesO)==nul"l) 

{pi 1 oteWeb. creerListeDesIntitulesAerodromesO ; } %> 

<% String [] nomsAerodromes = pi 1 oteWeb. getAe rod romes () ; %> 

<% String[] nomsIdAerodromes = piloteWeb.getldAerodromesO ; %> <- © 

<formulaire method="get" action="planDeVolDetail . jsp"> 

<1iste titre="Aerodrome de depart" nom="etapel"> 

<% for (int i=0; i<nomsAerodromes. length; i++) { %> 

<option value="<%= nomsIdAerodromes [i] %>"><%= nomsAerodromes [i] %> 

</option> 

<% } %> 

</liste> 
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<choix titre="Ajouter les points de reperes proches du plan de vol" 
nom="publ i ePoi ntsDeRepere" 

init="<%= piloteWeb.getPubliePointsDeRepereO %>"/> 
<choix titre="Afficher les pilotes proches de la zone" 
nom="publ i ePi 1 otesProche" 

init="<%= pi loteWeb.getpubliePil otesProche () %>"/> 
</formulai re> 

Dans cet extrait, on voit la recuperation de la variable indicee nomsIdAerodromes, 
calculee par le programme getldAerodromes (repere©). Cette liste sert ensuite a 
creer le menu deroulant grace a une boucle ecrite en JSP integree aux elements XML 
de definition d'un formulaire (la boucle en question est en gras dans l'exemple). 

Les balises utilisees dans cette couche metier ne sont pas encore des elements 
HTML ; ces derniers ne seront generes que par la derniere couche de 
programmation : la couche presentation programmed en XSLT. 



Figure 7-13 

Le menu deroulant de 
PiloteWeb affichant 
la liste des aerodromes 



Adresse L@J http://localhost : 808Q/exarru)tes/jspft)ilotewetylogin . jsp?emafl=jc@f rea . f r&pf d=Chauveau&sjbmit=Valider 




PH0tQ<WQb> 

L'etude de cas du cahier 
du developpeur de DTD XML 

accueil | aerodrome | plan de vol 



Etablisssement d'un plan de vol 



A titre d'exemple, vous pouvez considerer le plan de vol suivant : 
depart de Toussus pour St Nazaire via le Mans (etape 1). Vous 
pourrez constater qu'un point de repere visuel a ete ajoute a la 
route. Par ailleurs, Nantes etant sur le chemin entre Le Mans et St 
Nazaire est ajoute comme aerodrome de secours. 



Aerodrome de depart 

Etape n°1 

Etape n°2 

Etape n°3 

Aerodrome d'arrivee 



LFRM, Le Mans, Arnage T 



LFRZ, Saint Nazaire, Montoir I 



LFRM, Le Mars, Artiage 
LFRS, Nantes, Atlantique 



iLFRZ. Saint Nazaire. Montoir 



LFPN, Toussus, le Noble 



i rtioiiLei ley uoirny oe [eneiey piocties dj plan de vol 
r Affi cher les pilotes proches de la zone 



Valider 



© 2003 , Regis ranaro I o , 3te p h ane M a ri el. Je a n- Jacq u es The m assort. 
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Comme on peut l'observer au travers des extraits de pages JSP presentees dans cette 
section, les balises XML de la couche metier ne sont pas des elements HTML. Les 
elements utilises ne sont pas identiques aux balises qui servent au stockage (nous avons 
pu voir comment la couche de mise en correspondance construit a la volee de nouvelles 
structures XML) et ne sont pas encore des balises HTML du niveau presentation. En 
effet, le role principal de la couche metier est d'assembler differentes donnees pour leur 
donner un sens du point de vue d'une application, c'est-a-dire metier. 

Dans la prochaine section, nous allons etudier les transformations qui permettent de 
passer de la couche metier a la couche presentation. 

Programmation de la presentation (XSLT) 

Cette couche a pour objet d'amener les donnees XML a former une page HTML 
pleine et entiere. Pour ce faire, les constructions de type metier preparees dans la 
couche precedente vont etre transformees en HTML grace a une programmation 
XSLT. 

Comme nous allons le voir, la programmation XSLT peut : 

• ajouter des elements de presentation (bandeau de haut et pied de page, logos, 
copyright, etc.) ; 

• collecter et transformer les donnees recues de maniere importante (reorganisation, 
changement de valeurs, transposition texte/image, ajout de textes standards, etc.) ; 

• introduire des elements de programmation JavaScript ; 

• faire appel a une feuille de styles de type CSS activee quand la page HTML sera 
finalement affichee. 

Lajout d'elements de presentation dans les pages de PiloteWeb, tels que l'avion et le 
nom de 1' application, est typique car elle haurait pas lieu d'etre dans les couches 
amont de notre programmation. 

Void la programmation XSLT correspondante : 

<body> 

<table border="0" width="600" censpacing="0" ce"llpadding="0"> 
<tr><tdximg border="0" src="Img/pilotewebOO.png"/x/td> 
<tdximg border="0" src="lmg/pilotewebl0.png"/x/td> 
</tr> 
<tr> 
<td> 

<xsl :apply-templates select=""login" /> 
</td> 
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<td class="shortcuts" va"lign="middle" 

border="0" background="Img/pilotewebll.png"> 
<xs"l :apply-templates select="raccourcis/*" /> 
</td> 
</tr> 
</table> 

</body> 

On y repere l'appel des images du bandeau du haut, des boutons de connexion 
(login) ou sortie (quitter) de l'application et des menus (accueil, aerodrome, plan 
de vol). La figure 7-14 en presente le resultat. 



Figure 7-14 

Presentation obtenue par la 
transformation XSLT « fixe » 



Acfresse ^Jhttp://localhost: 8030Jexarriples/jsp/pifoteweb/login,pp?emaS=jc@f ree . f r&pwd=Chauveau&5ubmit=Valider 




Pilote<Web> 

L'etude de cas du cahier 
du developpeur de DTD XML 

accueil | aerodrome | plan de vol 



Etablisssernent d'un plan de vol 



Les transformations importantes de donnees sont visibles sur les donnees meteorolo- 
giques de PiloteWeb. 



Figure 7-15 

Affichage des donnees meteo- 
rologiques de PiloteWeb 



Donnees meteo : 

(Mayenne, France) 

Vent: 270°, 3 MpH (3 Kts), 

temperature : -3.3T (26.1°F), 

humidite : 65%, 

pression : 1021 hPa (in. Hg), 

visibility : 17 kms. 



Le programme de transformation XSLT effectue les transformations suivantes : 

• Determination des icones temperature, sens du vent et etat du ciel a partir des 
valeurs numeriques recues. Placement de ces icones en tete de la presentation de 
la meteorologie. 

• Concatenation des mots « Mayenne » et « France », ajout de la ponctuation. 
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Figure 7-16 

Donnees sources utilisees 
pour les informations 
meteorologiques 



<meteo> 

<departement>Mayenne</departement> 

<pays>France</pays> 

<vent unit=' degrees' >WWW 270</vent> 

<vitesse unit='mph'>3</vitesse> 

<vitesse unit='kt'>4</vitesse> 

<ciel>lcloud_fog</ciel> 

<temperature unit='F'>26.1</temperature> 

<temperature urnt='C'>-3.3</temperature> 

<humi di te>6 5%</humi di te> 

<pression unit='in.Hg'>30. 17</pression> 

<pression unit='hPa'>1021</pression> 

<visibilite unit='miles'>9</visibil ite> 

</meteo> 



• Transformation de la chaine de caracteres « WWW 270 » en « 270' ». Le « WWW » 
sert a choisir l'icone indiquant le sens du vent. 

• Changement de l'unite mph en MpH. 

• Conversion des miles en kilometres. 

Le XSLT permet d'introduire des scripts JavaScript. Dans PiloteWeb, on utilise une 
fonction ecrite en JavaScript qui s'intitule vacopen : 

<scn'pt> 

function vacopen (url) { 

open(url , 'vac' , ' too~lbar=no, 
~location=no, 
di rectories=no, 
status=no, 
menubar=no, 
scroll bars=yes , 
res"izable=yes, 
width=660, 
height=600'); 
return ; 
} 
</script> 

Cette fonction construit FURL d'une ressource. Elle est utilisee dans la programma- 
tion XSLT comme suit : 
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xsl :when test="boolean(@photo)"> 
<xsl: element name="a"> 
<xsl : attribute name="href"> 

javascript:vacopen('Img/<xsl :value-of select="@photo"/>') 
</xsl :attribute> 
<xsl:element name="img"> 
<xsl : attribute name="width">300</xsl :attribute> 
<xsl :attribute name="src">Img/<xsl :value-of select="@photo"/> 
</xsl :attribute> 
</xsl :element> 
</xsl :element> 
</xs1 :when> 

Enfin, la programmation XSLT introduit dans le fichier HTML final l'appel a une 
(ou plusieurs) feuille de styles CSS. Celle utilisee dans PiloteWeb fait l'objet de la 
section suivante. 

Programmation de I'affichage (HTML et CSS) 

Le fichier HTML resultant de la transformation XSLT commence ainsi : 

<htm"l> 

<head> 

<title>PilotWeb : le site des pilotes prives</title> 

<link rel="stylesheet" type="text/css" href="style/style.css"x/link> 

</head> 

La feuille de styles style. ess ne contient pas grand-chose, sinon quelques defini- 
tions typographiques de paragraphes. On se situe la au stade ultime des transforma- 
tions subies par les donnees XML stockees pour qu'elles puissent etre presentees a 
des utilisateurs finaux : 

a {color: #b50a0a;} 

p {text-align: justify;} 

p. center {text-align: center;} 

html, body {margin: Opx; 

padding: Opx; 

background: #b6e4fb; 

color: #2640a8; 

text-align: justify; 

f ont-f ami 1 y : hel veti ca , ari al ; 

font-size: 16px;} 



Etape 7 - Organiser les differentes couches de programmation 

Chapitre 7 



.question {text-align: right;} 

. reponse {font-family: helvetica, an'al; 

font-size: 16px; 

color: #2640a8;} 
img {border: Opx;} 
.shortcuts {text-align: right;} 
.titre {font-size: 18px;} 
td img {display: block;} 
p.meteo {font-size: 13px; 

text-align: left;} 



En resume... 



Dans ce chapitre, nous avons montre de facon concrete deux points fondamentaux de 
la conception des applications : 

1 La difference importante qui existe entre modeles de stockage et modeles d'affi- 
chage (ou restitution). Dans le detail de ce chapitre, nous avons meme vu qu'il 
existait des modeles intermediates, volatils, encore tres differents des deux autres. 

2 La necessaire organisation des couches de programmation d'une application. 
Certains traitements ne peuvent etre realises qu'avec certains langages de pro- 
grammation, d'autres doivent repondre a des criteres de mutualisation, d'autres 
encore a des logiques de programmation (la couche presentation en est un exem- 
ple typique : elle doit forcement arriver a la fin des traitements). 

II est certainement utopique de penser maitriser assez le code d'une application pour 
respecter totalement ces deux points, mais il est capital de tenir compte de leur existence 
qui tient principalement aux specificites de XML. Cela ameliorera de maniere significa- 
tive la possibilite de maintenance, l'extensibilite et la fiexibilite de vos applications. 

A partir du chapitre suivant, nous allons passer en revue des techniques de balisage 
que nous recommandons pour que, justement, vos applications soient le plus stan- 
dard possible et le plus facile a maintenir. 
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Modeles modulaires 



Nous allons maintenant decrire les techniques d'ecriture particulieres des modeles 
modulaires : l'une adaptee au cas des DTD, l'autre aux schemas XML. 

Les modeles modulaires, qu'il s'agisse de DTD ou de schemas XML, poursuivent le 
meme objectif : produire facilement plusieurs DTD ou schemas a partir d'un jeu 
reduit de structures. Ainsi, on obtient une flexibilite intrinseque au modele qui reside 
dans le fait qu'une modification appliquee a l'une des briques elementaires est reper- 
cutee sur l'ensemble des schemas l'utilisant. 

Linteret d'un tel precede est evident mais sa mise en ceuvre necessite quelques expli- 
cations. 

Le cas des DTD est distinct de celui des schemas XML : leurs mecanismes de 
modularisation sont differents. Aussi pour les illustrer avons-nous pris des exemples 
representatifs de chaque cas. Les deux exemples choisis sont celebres. II s'agit d'une 
part de la DTD DocBook destinee a l'edition de livres et d'autre part des schemas 
XML de la norme S1000D qui s' applique a la documentation des systemes d'armes 
et de defense. Nous allons montrer deux facons de rendre modulables ces modeles : 

• par le choix des elements racines ; 

• par la composition d'elements. 

La technique de composition d'elements peut etre mise en ceuvre de maniere meca- 
nique avec les DTD, tandis quelle est forcement logique dans le cas des schemas 
XML. Une composition est logique quand les petits morceaux resultant du decou- 
page sont eux-memes des schemas valides ; elle est mecanique dans le cas contraire. 
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Representation d'un modele modulaire 

Quand un modele est decompose en fragments se pose la question de sa 
representation : en effet, la decomposition peut ne pas correspondre a la logique du 
modele conceptuel, et les representations graphiques classiques des DTD et schemas 
partent toujours du principe que le modele est « expanse ». Ces representations ne 
disposent done d'aucune fonction de mise en evidence de la modularite. 

Le travail de representation a ete realise pour au moins l'un des deux modeles qui sert 
de trame a ce chapitre : la S1000D. Cette norme definit quinze classes de documents 
de type papier et catalogues allant des descriptions generates, le modele descri pt, a 
des catalogues de pieces detachees, le modele IPC. 

L'approche modulaire est naturelle pour documenter des materiels : 

• Une arborescence de modules peut facilement etre calquee sur la structure physi- 
que ou fonctionnelle d'un materiel. 

• La structure interne d'un module est generique, ce qui le rend utilisable tant pour 
la documentation d'un avion que pour celle d'un chargeur de batterie. 

Afin d'organiser les modeles, trois niveaux de structuration ont ete definis. lis sont 
presentes a la figure 8-1. 



Figure 8-1 

Les trois niveaux de structura- 
tion definis pour la S1000D 



1 

couche 2 


. 






Structures specif ques dune classe 
de documents 






1 

couche 1 


: 




Structures generiques de type document : 
paragraphed, listes, litres... 




1 
couche 


L 


Structures g^neriques : gestion des revisions, des 

applicabilities et des references croisees. identifcation des 

modules et de gestion des metadonnees 



Le modele est concu pour etre extensible. Cette volonte s'explique par le fait que la 
documentation de maintenance d'un avion ne se limite pas a l'objet physique avion, 
mais s'etend a tous les systemes terrestres et embarques qui l'accompagnent (pensons 
par exemple aux avions embarques a bord de porte-avions et aux systemes informati- 
ques necessaires sur le navire pour faire le relais avec ceux montes sur l'avion). 

Pour eviter les redondances et recoupements, le role de chaque modele de base a ete 
parfaitement defini. Le tableau 8-1 donne un apercu de la maniere dont les modeles 
ont ete decoupes. Ce tableau doit etre lu en pensant que les modeles de base ne fer- 
ment pas une organisation plane mais une pyramide de modeles de base, les uns 
s'emboitant dans les autres. 
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Tableau 8-1 Organisation des modeles de base d'un modele modulaire 
(extrait de la liste des DTD de base de la norme S1 000D) 



%acrwcfg; 


an rcrew.cfg 


Configuration des composants specifiques au type ai rcrew (equipage). 


%aecma; 


aecma.cfg; 


Configuration des composants de base de type aecma. 


%af; 


af .ent 


Decomposition des contenus de type af (air vehicle fault isolation). 


%aircrew; aircrew. ent 


Decomposition des contenus de type ai rcrew (equipage). 


%base; 


base. ent 


Composant de base des DTD S1000D. 


%capgrp; 


capgrp.ent 


Composant de type caption group. 


%common ; 


common .ent 


Composants generiques. 


%comps; 


comps.ent 


Catalogue des identifiants des differents composants. 


%descrpt; descript.ent 


Decomposition des contenus de type descriptif. 


%extappl ; appl i c . ent 


Decomposition de I'applicabilite. 


%extcont; 


content. ent 


Decomposition de base de I'element content. 


%extdmc; 


dmc.ent 


Decomposition de la codification des modules. 


%extf tab ; 


fig_tab.ent 


Decomposition des elements f i gu re et tab! e. 


%extlist; 


lists. ent 


Decomposition des listes. 


%extpara; paras. ent 


Decomposition des paragraphes. 


%extspec; specpara.ent 


Decomposition des paragraphes speciaux. 


%extstat; 


status. ent 


Decomposition de I'element status. 


%extstep; 


steps. ent 


Decomposition de I'element steps. 


%ipd; 


ipd. ent 


Decomposition des contenus de type ipd (illustrated parts data). 


%nic; 


nic.ent 


Decomposition des contenus de type nic (nomenclature, identification, CSN). 


%pmdata; 


pmdata.ent 


Decomposition des contenus de type pmdata (product management data). 


%prel req; 


prel req. ent 


Decomposition des contenus de type prelreq (preliminary requirements). 


%proced; 


proced.ent 


Decomposition des contenus de type procedure. 


%schedul ; 


schedul .ent 


Decomposition des contenus de type planification (schedule). 


%wcnp; 


wcnp.ent 


Composants des contenus de type wcnp (warning, caution, note, paragraphs). 



Chacun de ces fragments de DTD est associe a un identifiant public et a un nom 
d'entite, comme on peut le voir dans la colonne de gauche du tableau (pour les 
schemas XML, ces identifiants publics deviendront des noms d'espaces de noms). 

Une classe de documents est le resultat de l'assemblage des entires base de la 
couche 0, extcont de la couche 1, et enfin de celles de la couche 2 specifiques a la 
classe de document considered (par exemple, ipd pour un IPC). Les elements du 
niveau 2 viennent parfois redefinir des elements du niveau 1 ; par exemple, la version 
destinee au pilote contient des listes de controle (plus connues sous le nom de check- 
list) qui n'apparaissent pas dans le modele de base. 
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Ainsi, on peut representer le modele du modele de la S1000D bien qu'il ne s'agisse 
pas d'un modele conceptuel. Les figures 8-2 et 8-3 presentent les deux « macro- 
structures » qui font office de meta-modeles de la S1000D : celles des modeles des- 
criptifs (figure 8-2) et des procedures (figure 8-3) . 



Figure 8-2 

Macro-structure representant 
le modele du modele de 
description de la S1000D 
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Figure 8-3 

Macro-structure representant 
le modele du modele de 
procedures de la S1000D 



| proced.dtd 



comps.ent 



aecma.cfg 



common.ent 



base.ent 



proced.ent 



content.ent 



isolatl .ent 



dmc.ent 



isopub.ent 



isogrk3.ent 



isonum.ent 



isotech.ent 



status.ent "[] applic enT 











pmdata.ent 




prelreq.ent 
















nic.ent 




steps en 






lists.ent 






fig_tab.ent 






specpara.ent - 


wcnp.ent 
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Cette structuration des modeles a egalement ete suivie pour la definition des feuilles 
de styles XSL associees aux modules. En effet, la modularite des modeles doit 
s'accompagner d'une modularite equivalente des programmes associes. 



Cas des DTD 



Dans ce chapitre, nous presentons les techniques de modularisation des DTD. Nous 
examinerons tout d'abord un mecanisme base sur le choix des elements racines, puis 
un autre etabli sur la composition des elements. 



Choix des elements racines 

En SGML et XML 1.0, on peut sans probleme ecrire des DTD permettant aux 
documents XML instances d'avoir comme element racine tout element du modele. 
Nous allons rappeler comment fonctionne ce mecanisme de base. 

Soit une DTD simple : 

<! ELEMENT sites (site*)> 

<! ELEMENT site (nom, photo?, position)> 

<!ATTLIST site unique-id ID #REQUIRED> 

<! ELEMENT nom (#PCDATA)> 

<! ELEMENT photo EMPTY> 

<!ATTLIST photo nom CDATA #REQUIRED 

format (gif | jpg | png) "gif"> 
<! ELEMENT position (x,y)> 
<! ELEMENT x (#PCDATA)> 
<! ELEMENT y (#PCDATA)> 

Cette DTD definit sept elements : sites, site, nom, photo, position, x, y. 

Dans les documents XML conformes a cette DTD, on declare l'element racine en 
utilisant la carte DOCTYPE en debut de document, comme ci-apres. 

Premier exemple, l'element racine est sites : 

<?xml version="1.0" encoding="UTF-8"?> 

<!D0CTYPE sites SYSTEM "sites. dtd" []> <- sites est declare ici comme 

element racine 

<sites> 

<site unique-id="i 1"> 

<nom>Pi"lote de Demo</nom> 

<photo nom="pi ngouin.jpg" format="jpg"/> 
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<position> 

<x>48.7494</x> 

<y>-2.1108</y> 
</position> 
</site> 
</sites> 

Une fois la declaration faite, l'instance DOIT commencer par la balise <dmodule>. 

Dans notre second exemple, 1' element terminal code est la racine. On obtient une 
instance minimale, mais tout autant valide que celle du premier exemple par rapport 
a notre DTD. 

<?xml version="1.0" encoding="UTF-8"?> 

<!DOCTYPE code SYSTEM "exempleDTD.dtd" []> <- 1 'element racine ici 

declare est code 

<code>Text</code> 



VOCABULAIRE Element terminal 

En XML, un element terminal est un element qui ne contient pas lui-meme d'autres elements. Son seul 
contenu peut etre du texte ou rien du tout (cas des elements vides). 



VOCABULAIRE Feuille 

Une structure XML etant assimilee a un arbre, les elements terminaux sont egalement appeles les feuilles 
de cet arbre. 



Aparte Une difference entre SGML et XML 

Puisque Ton parle de DTD, il faut noter qu'en XML, la carte DOCTYPE ne peut etre utilisee que dans les 
instances. Elle est interdite dans les DTD. Ce detail change singulierement les possibilit.es d'attribution de 
I'element racine : en SGML, la carte DOCTYPE pouvait etre utilisee dans les DTD, autorisant ainsi les con- 
cepteurs a imposer aux utilisateurs I'element racine a employer. Cependant, chaque DTD ne pouvait se 
voir attribuer qu'un seul element racine. 



Avec ce mecanisme, les concepteurs de DTD ne peuvent pas imposer aux utilisateurs 
de demarrer leurs documents XML par un element precis : tous sont permis. Rien 
nest done controle. C'est une forme de flexibilite qui ne correspond pas au souhait 
legitime des concepteurs de DTD en matiere de controle de la modularite de leurs 
modeles. 
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Composition d'elements 

Le modele de la DTD DocBook a cette caracteristique remarquable qu'un tres grand 
nombre d'elements et d'attributs y sont definis. 



HlSTOlRE Le modele DocBook 

Le modele DocBook date de 1991 et a traverse les epoques SGML, HTML, XML et enfin XML Schema. 
Son origine est a la fois technique et editoriale puisque ses concepteurs etaient respectivement le fabri- 
cant d'ordinateurs Hal Computer Systems et la maison d'edition O'Reilly & Associates, lis se sont inspires 
des travaux conduits a I'epoque par I'OSF (Open Software Foundation) pour I'interoperabilite d'Unix : 
SGML etait alors envisage comme format d'ecriture des manuels de reference des versions OSF d'Unix. 
Le modele initial a ete rapidement repris par le groupe de Davenport, du nom du lieu ou se tint sa pre- 
miere reunion, reunissant les producteurs de documents et livres sur I'informatique : O'Reilly, Novell et 
Digital. Le modele DocBook devint officiellement I'affaire du groupe de Davenport en 1 994. 
La derniere version officielle de DocBook est la V4.3, en date du 31 mars 2004. Celle que nous utilisons 
dans ce chapitre est la V4.2 du 1 7 juillet 2002. Le modele DocBook est I'un des rares modeles a etre dis- 
ponible dans tous les langages de modelisation possibles : SGML et XML 1 .0 pour les versions officielles, 
XML Schema, RelaxNG et Trex pour les versions non officielles. Ainsi, on peut done comparer ces diffe- 
rents langages de modelisation. 



Avec DocBook, on entre dans le domaine des mega-DTD. Les statistiques concer- 
nant ce modele sont impressionnantes : 388 elements y sont definis, dont 
185 mixtes, 18 vides et 21 recursifs. Sur ces elements, pas moins de 4548 attributs 
sont declares, dont 109 differents (en nom et en type). La version XML Schema fait 
82491ignes... 

Ce qui est interessant, e'est la maniere dont le modele gere cette complexite. Sans 
aller jusqu'a parler de la flexibilite des documents XML ecrits en DocBook, la ques- 
tion posee ici est veritablement celle de la flexibilite du modele lui-meme ! 

La technique de gestion utilisee est differente selon le langage de modelisation uti- 
lise. Pour les versions SGML et XML, la modularite du modele est geree avec la 
technique des sections marquees : la totalite du modele tient dans un seul fichier, 
dont certaines parties peuvent etre incluses ou exclues grace au mecanisme des sec- 
tions marquees de SGML et XML. 

La XML Schema ne peut utiliser ce mecanisme qui n'existe pas dans cette version : 
elle s'appuie sur des fichiers contenant des sous-schemas. Nous aborderons cette 
question a la prochaine section de ce chapitre. 

Nous presentons ci-apres quelques traits caracteristiques de la technique des sections 
marquees. Nous commencons avec un extrait de la DTD bi-format SGML/XML : 
une DTD qui contient les syntaxes SGML et XML d'ecriture de DTD. 
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Dans le premier extrait expose ci-apres, 1'initialisation principale gouverne la totalite 
du jeu d'instructions permettant de passer d'un langage a 1' autre. Les deux entires 
parametres sgml .features et xml. features sont initialisees avec les valeurs IGNORE et 
INCLUDE. Ces entites parametres s'excluent mutuellement (si l'une vaut IGNORE, 
l'autre doit valoir INCLUDE, et vice-versa). Cela permet de basculer de la version XML 
(quand xml .features vaut INCLUDE) a la version SGML de la DTD (quand 
sgml . features vaut INCLUDE). 

Dans l'extrait ci-apres, remarquez comment les deux entites parametres sont imme- 
diatement mises en oeuvre comme criteres de selection des sections marquees 
(repere ©). 



ENTITY % sgml .features "IGNORE"> 

[%sgml .features; [ <- © 

ENTITY % xml. features "IGNORE"> 

> 

ENTITY % xml. features "INCLUDE"> <r O 

[%sgml .features; [ <- © 
ENTITY % ho "- 0"> 
ENTITY % hh "- -"> 



]]> 



[%xml .features; [ <- © 
ENTITY % ho ""> 
ENTITY % hh ""> 



]]> 

Explications : 

L'entite parametre sgml .features est initialisee : 

• Si sa valeur est IGNORE, la section marquee reperee est ignoree du parseur qui 
passe directement a 1'initialisation de l'entite parametre xml .features qui vaudra 
alors INCLUDE. 

• Si sa valeur est INCLUDE, la section marquee reperee © est prise en compte par le 
parseur qui initialise l'entite parametre xml .features avec la valeur IGNORE. La 
seconde initialisation de cette derniere entite parametre (repere O) ne sera pas 
prise en compte par le parseur car une regie etablit que c'est toujours la premiere 
initialisation d'une entite parametre qui fait sa valeur finale. 



VOCABULAIRE Entite parametre 

Une entite parametre est une variable qui n'a le droit d'etre utilisee que dans une DTD. On la reconnatt 
grace au caractere % qui suit immediatement le mot-cle ENTITY. 
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Les reperes © et © correspondent a des sections marquees, montrant comment les 
entites parametres definies au debut peuvent servir a definir de maniere conditionnelle 
d'autres entites parametres, qui, a leur tour, correspondent a des morceaux de DTD. 

En l'occurrence, on montre comment une difference de syntaxe entre DTD SGML 
et DTD XML peut etre prise en compte. Le repere © correspond a la syntaxe 
SGML : utilisation dans les DTD de la chaine de caracteres "- O" pour indiquer les 
minimisations de balisage autorisees. Le repere © correspond a celle de XML ou, ces 
minimisations n'etant pas autorisees, la chaine de caracteres correspondante est tout 
simplement vide. 

Ce mecanisme, qui rend possible la manipulation physique de la DTD (dans notre 
exemple, nous supprimons ou ajoutons physiquement des chaines de caracteres dans 
la DTD), peut etre utilise pour la modifier logiquement : on peut ainsi rendre 
variable le modele que la DTD definit. 

Nous allons expliquer la facon dont ce mecanisme a ete utilise dans la DocBook 
apres en avoir donne un exemple caracteristique. 

Void un extrait de la DTD qui va nous servir d'exemple : 

<! ENTITY % local. docinfo. char. class ""> <r © 

<!ENTITY % docinfo. char. class "author | authorinitials | corpauthor 

Imodespec lothercredit | productnamel 
productnumber | revhi story 
%local .docinfo. char. class; "> 

Cet extrait est typique de la maniere dont la DTD DocBook a ete ecrite : une classe 
d'elements (ici, la classe doci nf o . char . cl ass) est une entite parametre qui represente 
un fragment de modele de contenu. 

Ce dernier est extensible de la maniere suivante : 

• Une entite « compagnon » est adjointe a l'entite principale : 
local. docinfo. char .class. 

• Dans la DTD de base, cette entite est vide (repere ©). 

• II suffit de la faire preceder d'une autre declaration pour que sa nouvelle valeur soit 
prise en compte. En effet, comme c'etait deja le cas avec les DTD SGML, c'est la 
premiere initialisation d'une entite qui fige le contenu des DTD de XML 1.0. 

Ainsi, avec la serie de declarations suivantes, le contenu de l'entite 

docinfo. char. class sera "author | authorinitials | corpauthor | modespec | 

othercredit | productname | productnumber | revhi story | isbn | 
issuedate | pubdate" : 

<!ENTITY % local .docinfo. char. class " | isbn | issuedate | pubdate"> 
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<! ENTITY % local .docinfo. char. class ""> 

<!ENTITY % docinfo. char. class "author | authorinitials | corpauthor 

|modespec|othercredit | productnamel 
productnumber | revhi story 
%local .docinfo. char. class; "> 

En XML Schema, cette technique est impossible. Le concept d'entite parametre 
n'existe tout simplement pas et, pour des raisons qui sont faciles a expliquer, aucun 
mecanisme n'a ete prevu pour compenser cette absence. 



Information Pourquoi le mecanisme des entites parametres n'existe-t-il pas en 
XML Schema ? 

XML Schema repose sur des constructions parfaitement logiques de modeles. Les sous-schemas doivent 
etre eux-memes des schemas valides, independamment de tout autre schema. Le mecanisme des entites 
parametres qui fait qu'on peut mettre n'importe quel bout physique de DTD dans n'importe quelle varia- 
ble ne correspond pas du tout a cette logique. C'est pourquoi le mecanisme des entites parametres n'a 
pas de raison d'etre en XML Schema. 



C'est pourquoi la logique mise en oeuvre pour construire les DTD de DocBook n'a 
pas pu etre transposee, le mecanisme des entites parametres faisant defaut. Dans la 
version XML Schema de DocBook, le modele docinfo. char. class n'est pas 
extensible : 



<xsd: group name= 
<xsd:choice> 
<xsd: element 
<xsd: element 
<xsd: element 
<xsd: element 
<xsd: element 
<xsd: element 
<xsd: element 
<xsd: element 
</xsd:choice> 
</xsd:group> 



"doci nfo. char .class "> 

ref="db:author"/> 
ref="db : authori ni ti al s"/> 
ref="db:corpauthor"/> 
ref="db : modespec"/> 
ref="db:othercredit"/> 
ref="db : productname"/> 
ref="db: productnumber"/> 
ref="db: revhistory"/> 



Afin de gerer la complexite des imbrications possibles d'entites parametres, les cas de 
figure geres par DocBook sont savamment decrits dans des tableaux de configuration 
tels que celui que nous fournissons ci-apres. lis ne representent pas directement les 
modeles de contenus finaux mais plutot des macro-structures, qui pourraient porter le 
nom de formes architecturales de la DTD, elles-memes entites parametres utilisees 
dans d'autres macro-structures. Un exemple vient plus bas a l'appui de notre propos. 
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Tout d'abord, commencons par montrer le tableau qui sert a exprimer les combinai- 
sons autorisees de macro-structures : 

:! -- 

list admn line synp para infm form cmpd gen desc 

X 



Component 


X 


X 


X 


X 


X 


X 


X 


X 


X 


Sidebar 


X 


X 


X 


X 


X 


X 


X 


a 


X 


Footnote 


X 




X 


X 


X 


X 








Example 


X 




X 


X 


X 


X 








Highlights 


X 


X 






X 










Paragraph 


X 




X 


X 




X 








Admonition 


X 




X 


X 


X 


X 


X 


b 


c 


Figure 






X 


X 




X 








Table entry 


X 


X 


X 




X 


d 








Glossary def 


X 




X 


X 


X 


X 




e 




Legal notice 


X 


X 


X 




X 


f 









Puis, continuons en donnant un exemple d'une de ces macro- structures : 

<! ENTITY % local .component. mix ""> <- Entite utilisee dans une 

macrostructure 
<! ENTITY % component. mix <- Macrostructure ou forme architecturale 

de model isati on 
" %li st. class; | %admon. class ; | %linespeci fie. class; | %synop. class; 
I %para. class; | %informal .class; | %formal .class; | %compound. class; 
I %genobj . class ; | %descobj .class; | %ndxterm. class; | beginpage 
%local .component. mix; "> <- Utilisation de 1 'entite 

1 ocal . component . mi x 

Au final, les macro-structures sont utilisees dans des definitions d'elements dans les- 
quelles elles sont combinees avec des declarations d'elements ecrites en dur. Dans 
l'exemple ci-apres, la macro-structure component . mi x est combinee a l'element title : 

I <!ELEMENT msgexplan %ho; (title?, (%component . mi x ; ) +) > 



ASTUCE True technique 

Dans la DTD DocBook, la compatibility SGML/XML est assuree, entre autres, par I'utilisation de 
I'entite ho. Cette derniere rend variables les options de minimisation qui existent en SGML et pas 
en XML. Le mecanisme regissant cette entite est presente au debut de la section. 
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En version XML Schema, le modele de contenu de cet element est defini ainsi : 

<xsd: complexType name="msgexplan"> 
<xsd:sequence> 
<xsd:element ref="db: title" minOccurs="0"/> 
<xsd:choice minOccurs="0" maxOccurs="unbounded"> 

<xsd:group ref="db: component. mix"/> <- © 
</xsd:choice> 
</xsd:sequence> 

<xsd:attributeGroup ref="db: common. attrib"/> <- 
<xsd:attributeGroup ref="db:msgexplan. role.attrib"/> <- 
</xsd : compl exType> 

On y trouve la presence de 1' element title et du groupe component. mix. Remarquez 
que les objets composant ce type, le groupe comme les attributs, sont definis globale- 
ment dans un espace de noms specifique (identifie par le prefixe db). Dans la defini- 
tion du type complexe msgexplan, ils ne sont que references (repere 0). 

Le mecanisme est identique pour les attributs. 



Cas des schemas XML 



Choix des elements racines 

Contrairement a XML 1.0, XML Schema prevoit des mecanismes pour limiter le 
choix des elements racines. Cela donne trois cas de figure : 

• Un seul element est racine. 

• Tous les elements peuvent etre racines. 

• N elements des m definis par le schema peuvent etre racines. 

II suffit pour cela d'utiliser le mecanisme des declarations globales et locales. Avec les 
schemas XML de la recommandation XML Schema du W3C, tout element defini 
globalement peut etre racine d'un document XML valide par rapport a ce schema, 
tandis qu'aucun element defini localement ne peut l'etre. 

Nous allons presenter ci-apres quelques exemples, apres conversion de la DTD 
sites, utilisee en schema XML. 

Exemple : un schema XML ou tous les elements sont globaux : 

<?xml version="1.0" encoding="UTF-8"?> 

<xs : schema xml ns : xs="http : //www. w3 . org/2001/XMLSchema" 
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el ementFormDef aul t="qual i f i ed"> 
<xs: element name="nom" type="xs:string"/> 
<xs: element name="photo"> 
<xs : compl exType> 
<xs: attribute name="nom" type="xs: string" use="requi red"/> 
<xs: attribute name="format" default="gif"> 
<xs:simpleType> 
<xs: restriction base="xs :NMTOKEN"> 
<xs: enumeration value="gif "/> 
<xs : enumeration val ue=" jpg"/> 
<xs: enumeration value="png"/> 
</xs : restri cti on> 
</xs:simpleType> 
</xs:attribute> 
</xs : compl exType> 
</xs:element> 

<xs: element name="position"> 
<xs : compl exType> 
<xs:sequence> 
<xs: element name="x" ref="x"/> 
<xs: element name="y" ref="y"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 
<xs: element name="site"> 
<xs : compl exType> 
<xs:sequence> 
<xs: element name="nom" ref="nom"/> 

<xs:element name="photo" ref="photo" minOccurs="0" maxOccurs="l"/> 
<xs:element name="position" ref="position"/> 
</xs:sequence> 

<xs:attribute name="unique-id" type="xs:ID" use="requi red"/> 
</xs : compl exType> 
</xs:element> 
<xs: element name="sites"> 
<xs : compl exType> 
<xs:sequence> 
<xs:element name="site" ref="site" minOccurs="0" 
maxOccurs="unbounded"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 

<xs: element name="x" type="xs :string"/> 
<xs: element name="y" type="xs :string"/> 
</xs:schema> 



Modeles de reference 

Deuxieme partie 



Ce schema permet, comme dans le cas des DTD XML, d'utiliser comme racine des 
documents XML tout element defini dans le schema. Par exemple, on peut utiliser 
indifferemment les elements sites et code, et obtenir les documents valides 
suivants : 



<?xml version="1.0" encoding="UTF-8"?> 

<si tes xml ns : xsi ="http : //www . w3 . org/2001/XMLSchema-i nstance" 

xsi :noNamespaceSchemaLocat"ion="sites.xsd"> <- la racine est sites 

<site unique-id="il"> 

<nom>Pi"lote de Demo</nom> 

<photo nom="pi ngouin.jpg" format="jpg"/> 

<position> 

<x>48.7494</x> 

<y>-2.1108</y> 
</position> 
</site> 
</sites> 

<?xml version="1.0" encoding="UTF-8"?> 

<code xml ns: xsi =" http://www.w3 . org/2001/XMLSchema- instance" 

xsi :noNamespaceSchemaLocation="sites.xsd"> <- la racine est code 

contenu textuel de 1 'element</code> 



Composition d'elements 

Pour presenter le mecanisme de composition d'elements avec les schemas XML, 
nous allons nous appuyer sur les modeles realises par le groupe de travail EPWG de 
la norme S1000D. 

Un peu comme avec les DTD, la solution retenue ici consiste a ce que plusieurs 
schemas principaux soient definis par des combinaisons sophistiquees de schemas de 
base. Ainsi, si l'element racine des documents XML conformes a la S1000D est tou- 
jours l'element dmodule, on compte plus d'une dizaine de schemas XML differents 
(definissant autant de types de documents differents) qui resultent de la combinaison 
d'environ quatre-vingts schemas de base. 

Le modele repose sur les postulats suivants : 

• Aucun espace de noms cible particulier n'est defini afin de conserver une totale 
modularite du modele lui-meme (repere ©). 

• La modularite est assuree par des inclusions de schemas de base (repere O). 

• Les modeles de contenu des elements sont definis en utilisant le mecanisme des 
groupes, et non en suivant les mecanismes de derivation de types de 
XML Schema (repere ©). Les noms de groupes sont ainsi utilises comme des 
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variables, ce qui donne un effet similaire a celui qu'on a pu obtenir avec les entires 
parametres des DTD (voir section precedente). 

Void le schema principal des documents de type « crew », reduit a 1' assemblage de 
schemas de base au moyen du mecanisme d'inclusion de XML Schema (repere O). 

<?xml version="1.0"?> 

<xs:schema xmlns:xs="http://www.w3 .org/2001/XMLSchema"> <- 



<xs: include schemaLocation= 
<xs: include schemaLocation= 
<xs: include schemaLocation= 
<xs: include schemaLocation= 
<xs: include schemaLocation= 
<xs: include schemaLocation= 
<xs: include schemaLocation= 
<xs: include schemaLocation= 
</xs: schema> 



"project .cfg"/> <- O 

"common. xsd"/> <- O 

"base.xsd"/> <- O 

"capgrp.xsd"/> <- O 

"crew.xsd"/> <- O 

"fig_tab.xsd"/> <- O 

"content .xsd"/> <- O 

"paras. xsd"/> <- O 



Parmi les schemas de base, Fun se singularise, il s'agit de crew.xsd. En effet, c'est ce 
schema qui determinera la veritable structure finale des documents de type « crew ». 
Nous n'en donnons ici que les extraits les plus interessants pour notre propos. 

<?xml version="1.0"?> 

<xs:schema xmlns:xs="http://www.w3 .org/2001/XMLSchema"> <- 

<xs:include schemaLocation="heading.xsd"/> <- O 

<xs:include schemaLocation="wcnp.xsd"/> <- O 

<xs:include schemaLocation="paracon.xsd"/> <- O 

<xs:include schemaLocation="lists.xsd"/> <- O 

<xs: group name="CONTENT"> <- © 

<xs:sequence> 
<xs: element ref="acrw"/> 

</xs:sequence> 
</xs :group> 



<xs: group name="NPAR"> 
<xs:sequence> 
<xs: element ref="warning" minOccurs 
<xs: element ref="caution" minOccurs 
<xs:group ref="NP" minOccurs="0"/> 
<xs: element ref="drill" minOccurs="0"/> 
</xs:sequence> 
</xs :group> 



<r © 



0" 


maxOccurs= 


'unbounded 


'/> 


0" 


maxOccurs= 

<r © 


'unbounded 


7> 
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<xs: element name="dri"N"> 
<xs : compl exType> 
<xs: choice maxOccurs="unbounded"> 
<xs:group ref="fft_inc" minOccurs="0" maxOccurs="unbounded"/> <" © 
<xs: group ref="DRLINTRO"/> <- © 
<xs:cho"ice minOccurs="0" maxOccurs="unbounded"> 
<xs: group ref="STEPS" maxOccurs="unbounded"/> <- © 
<xs:element ref="subdrill " minOccurs="0" maxOccurs="unbounded"/> 
</xs: choice> 

<xs:element ref="endmattr" minOccurs="0"/> 
</xs:choice> 

<xs:attribute ref="drilltyp"/> 
<xs: attribute name="ordered" defau"lt="on"> 
<xs:simpleType> 
<xs: restriction base="xs:NMTOKEN"> 
<xs :enumeration value="on"/> 
<xs :enumeration value="off"/> 
</xs: restricti on> 
</xs : si mpl eType> 
</xs:attribute> 

<xs:attributeGroup ref="bodyatt"/> <- © 
<xs:attributeGroup ref="secur"/> <- © 
</xs : compl exType> 
</xs:element> 



</xs: schema> 

Void enfin le schema de base base.xsd qui, contrairement a ce que Ton pourrait 
penser, fait appel a d'autres schemas de base (repere O). 

<?xml version="1.0"?> 

<xs: schema xmlns:xs="http://www.w3 .org/2001/XMLSchema" 

xmlns: rdf=" http://www.w3.Org/1999/02/22-rdf-syntax-ns#"> 
<xs: import names pace=" http://www.w3 .org/1999/02/2 2 -rdf- syntax- ns#" 

schemaLocati on=" rdf . xsd"/> 
<xs:include schemaLocation="dmc.xsd"/> <- O 

pmc.xsd"/> <- O 
status. xsd"/> <- O 



<xs: include schemaLocati on= 
<xs: include schemaLocati on= 
<xs: element name="dmodule"> 
<xs : compl exType> 
<xs:sequence> 
<xs:element ref="rdf :Description" minOccurs="0"/> 
<xs: element ref="idstatus"/> 
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<xs: element ref="content"/> 
</xs:sequence> 

<xs: attribute name="id" type="xs :ID"/> 
</xs : compl exType> 
</xs:element> 

<xs: element name="idstatus"> 
<xs : compl exType> 
<xs:sequence> 
<xs: element ref="dmaddres"/> 
<xs: element ref="status"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 

<xs: element name="techname" type="xs:string"/> 
<xs: element name="infoname" type="xs:string"/> 

<xs:simpleType name="N0NNEGI2"> 

<xs: restriction base="xs: nonNegativeInteger"> 
<xs:totalDigits value="2" fixed="true"/> 

</xs: restriction> 
</xs : si mpl eType> 

<xs: element name="issdate"> 
<xs : compl exType> 

<xs:attributeCroup ref="DATE"/> ^" © 
</xs : compl exType> 
</xs :element> 



</xs: schema> 

La difficulte que presente une telle organisation reside bien sur dans la constitution 
de la pyramide de schemas de base ; en effet, les modeles definis a la base de la pyra- 
mide doivent etre utilises par des modeles des etages superieurs sans risque de colli- 
sion ni de boucle. Cela serait le cas si un modele du niveau de base utilisait des cons- 
tructions definies dans des modeles de niveau superieur. 

XML Schema impose un controle parfait des schemas de base. En effet, une regie 
importante de ce langage dit que chaque modele, quels que soient sa taille et son role 
dans l'architecture des modeles, doit etre valide. Tout schema de base doit ainsi obli- 
gatoirement etre un schema valide, independamment de tout schema l'utilisant. 
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En resume... 

La creation de schemas modulaires pouvant se composer les uns avec les autres ne 
releve pas d'un mecanisme de derivation de type, contrairement a ce que pourrait 
laisser croire l'usage commun. Pour ce faire, on utilise la technique des types/elements 
parametrables (template class en UML). En DTD, ce role est devolu aux ENTITY. 
En XML Schema, un mecanisme equivalent est disponible au moyen des groupes. 

Dans ce chapitre, nous avons etudie la maniere d'ecrire des DTD et schemas modu- 
laires, soit en agissant sur les elements racines, soit en ecrivant les modeles de 
maniere a composer les elements. 

Pour definir des modeles modulaires, on factorise ce qui se trouve etre commun a 
plusieurs modeles. Le seul veritable risque, c'est d'avoir des difficultes a mesurer les 
consequences d'une modification d'un modele de base sur l'ensemble des autres 
modeles. Aussi, nous avons montre dans ce chapitre comment representer les 
modeles de maniere macroscopique. 

Le mecanisme des entites parametres qu'on peut utiliser pour les DTD modulaires 
n'a pas ete reconduit en XML Schema et il faut utiliser d'autres artifices pour obtenir 
un resultat similaire. La solution la plus simple et la plus flexible est de passer par des 
groupes. 

Nous verrons dans le chapitre suivant une variante de l'approche modulaire pour les 
modeles. Elle consiste a integrer dans les modeles des elements qui n'ont d'autre role 
que de decouper le modele en cas de besoin. 
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Elements purement 

structurels 



Ce chapitre va etre l'occasion de travailler sur un concept important, celui d'elements 
purement structurels. Nous allons notamment nous interesser : 

• au role et a l'importance des elements purement structurels ; 

• a la procedure a suivre pour identifier les elements purement structurels d'un 
schema XML. 

L'expression « element purement structurel » ne fait pas partie de la terminologie 
propre a XML Schema, et n'appartient d'ailleurs pas a une quelconque terminologie 
officielle du monde XML. Elle a ete elaboree en 1993, a une epoque ou Ton ne par- 
lait pas encore de XML, ni de XML Schema, et encore moins de document XML 
bien forme et d'espaces de noms. 



HlSTOlRE Element purement structurel 

Cette expression a ete elaboree en 1 993 par un groupe de travail sur les bases de donnees SGML reunis- 
sant Ludovic van Vooren et I'un des auteurs de cet ouvrage, Jean-Jacques Thomasson, qui travaillaient a 
I'epoque pour le compte de la societe Interleaf. Ludovic van Vooren est connu de la communaute SGML 
pour avoir developpe Mark-It, premier parseur SGML, sous I'egide d'un projet commande a la societe 
Sema Group Belgium par la communaute europeenne. 



Etapes de la demarche de modelisation 

Premiere partie 

Cette terminologie a done l'avantage d'etre affranchie de toute attache directe avec 
une application particuliere de XML, qu'il s'agisse d'un mecanisme, d'une recom- 
mandation ou d'un vocabulaire particulier. Cela lui permet d'etre l'unique represen- 
tant d'une theorie et d'une methode d'analyse qui se veulent universelles, e'est-a-dire 
valables pour n'importe quelle application XML, et meme au-dela du seul monde 
XML. La theorie que nous allons etudier dans ce chapitre permet de mieux com- 
prendre comment l'information, au sens le plus large du terme, est, ou peut etre, 
structuree. 

La theorie des elements purement structurels offre un point de vue autorisant l'ela- 
boration de meilleurs modeles XML. 

II s'agit d'elements XML dont le role dans la structure est singulier : en effet, ils ont 
un pouvoir structurant superieur aux autres. Ils sont a un schema XML ce que nos 
propres articulations sont au squelette humain : ils donnent de la souplesse a la struc- 
ture tout en amarrant solidement les membres entre eux. 

Apres avoir rappele les origines du concept, nous montrerons la procedure qui 
permet, dans un schema XML existant, de decouvrir parmi les elements ceux qui 
sont purement structurels. 



Genese de la theorie des elements purement structurels 

Pour presenter le concept d'element purement structurel, nous allons partir du prin- 
cipe que les structures en forme de poupees russes de XML sont comparables a une 
arborescence de fichiers, et gager ainsi d'une hypothetique (et trompeuse. . .) analogie 
entre les deux. 

Dans le tableau 9-1, nous exposons un fragment XML et, a sa droite, sa representa- 
tion sous forme de dossiers et de fichiers. 

Dans la suite de ce chapitre, nous detaillerons cette representation de la structure, et 
montrerons pourquoi la transposition proposee ici n'est pas realiste et ne peut done 
pas etre systematisee. A ce stade, les elements intermediates de la structure ont ete 
representes par des repertoires, les elements terminaux par des fichiers, et les attri- 
buts n'ont pu etre representes. 

En cherchant a representer ainsi un document XML, on souleve immanquablement 
les questions suivantes : 

1 Peut-on assimiler une balise XML a un fichier ? 

2 Ou doit-on mettre les attributs ? 

3 Que faire des metadonnees qui s'appliquent a tout le document ? 
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Tableau 9-1 Analogie entre un fragment XML et un systeme de fichiers 




Analogie avec un systeme de fichiers 


<doc> 




<volume tocentry="l"> 
<docpart> 
<front security="u"> 
<idinfo ven'fied="0" security="u"/> 
<revnum security="u"/> 


B-Q doc 

B-Q volume 
B{_D docpart 

J^ idinfo.txt 
J^ revnum.txt 


</f ront> 




</docpart> 




</vo"lume> 




</doc> 





Le premier point tient du bon sens. II provient d'une reflexion simple qui consiste a 
se demander s'il est concevable de gerer un document XML en le fragmentant 
jusqu'au plus petit de ses elements. En d'autres termes, faut-il vraiment attendre 
d'avoir atteint le niveau terminal pour passer a un stockage sous la forme de fichiers ? 

Le deuxieme point tient a la forme du XML : l'analogie avec un systeme de fichiers 
permet de representer visuellement la structure d'un document XML. Or, la ramener 
a une serie d'elements emboites les uns dans les autres est reducteur. Les attributs 
contiennent une information qui est parfois aussi importante que celle des elements. 

Le troisieme point est une generalisation du probleme de la representation des attri- 
buts du point precedent. Les metadonnees d'un document sont generalement consti- 
tutes par des elements places en debut de document XML. Leur role est de qualifier 
l'ensemble du document ou des elements du document en particulier. Rapidement, 
on s'apercoit qu'il s'agit d'elements qui, bien que freres ou enfants directs d'autres 
elements, les qualifient. Ces elements jouent le role d'attributs : la logique XML de 
l'arborescence est rompue. 

Comme vous allez le decouvrir dans les sections suivantes, l'etude de ces trois points 
met en evidence trois categories d'elements : les elements de donnees, les elements de 
donnees glob aux et les elements purement structurels. 

La reflexion que nous proposons dans les sections suivantes ha d'autre objet que de 
faire comprendre pourquoi les elements d'un document XML ne sont pas tous 
egaux, contrairement a ce que Ton pourrait penser a premiere vue. 



Peut-on assimiler une balise XML a un fichier ? 

Quand on cherche a gerer des modules d'information, on se pose tot ou tard la ques- 
tion de savoir quelle est la taille ideale d'un module. Doit-on aller jusqu'a des gra- 
nules minuscules ou faut-il qu'ils aient une certaine taille ? 
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Un document XML a ceci de particulier qu'il peut contenir des balises jusqu'a la plus 
infime des donnees, au moindre des caracteres. Or, cela a-t-il un sens de gerer de si 
petites unites d'information ? 

Pour repondre a cette question, nous pourrions repondre que cela depend de la 
nature de la donnee, de Implication, et qu'il faut juger au cas par cas. Toutefois, cette 
reponse ne permet pas de mettre en place une quelconque technique objective d'ana- 
lyse des schemas. La reponse doit etre trouvee par la seule analyse du schema. 

Pour cela, nous allons nous souvenir que XML Schema reconnait quatre types 
d'elements : a contenu simple, a contenu complexe, a contenu mixte et enfin a con- 
tenu vide. Le tableau 9-2 rappelle ce que signifie chacun de ces cas. 

Tableau 9-2 Les quatre types d'elements de XML Schema 



Type d'element 


Type de contenu 


Presence de texte Presence de sous-elements 


Element simple 


Oui 


Non 


Element complexe 


Non 


Oui 


Element mixte 


Oui 


Oui 


Element vide 


Non 


Non 



En tentant la correspondance balise/fichier du point de depart de notre reflexion, on 
s'apercoit qu'il n'est pas de solution simple. Nous allons le constater au cas par cas 
dans les sections suivantes. 



Cas des elements simples 

Ces elements ne contiennent que du texte, lequel peut etre vide quand le concepteur 
du schema XML l'a autorise (en ayant precise nillable=true dans la definition de 
1' element). 

Puisqu'un texte ne peut etre stocke ailleurs que dans un fichier, les elements de type 
simple sont obligatoirement assimiles a des fichiers et la seule question est de savoir 
si la balise doit etre elle-meme incluse dans le fichier ou si le nom de l'element doit 
devenir celui du fichier. Ces deux possibilites sont illustrees au tableau 9-3. 

Pvien ne permet de pencher en faveur de l'une ou de l'autre de ces deux representa- 
tions, sauf qu'on pourra noter que la seconde representation dissocie l'element p de 
son contenu textuel. 

Les elements de type simple sont des elements de donnees. 
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Tableau 9-3 Representation d'un element simple par un fichier 



Exemple d'element a contenu simple 


Premiere representation possible 


<p>L'utilitaire CATSTA est utilise 


Un fichier portant un nom banal contient I'ensem- 


pour traiter des donnees 


ble du fragment, c'est-a-dire le texte et les deux 


statistiques et comptables sous VM 


balises : 


et MVS.</p> 


H] fichier.txt 




Seconde representation possible 




Le fichier porte le nom de I'element (p) et ne con- 




tient que le texte du fragment : 




(ly p.txt 



Cas des elements complexes 

Alors que les elements de type simple sont les extremites, ou feuilles, de l'arbre que 
represente un document XML, les elements complexes en constituent les branches et 
les ramifications. Un type complexe ne peut avoir comme enfant que des sous-ele- 
ments. Si, dans notre analogie, la correspondance avec un dossier semble etre 
acquise, nous allons voir qu'il n'en est rien. L'analogie entre un element complexe et 
un dossier depend en realite de la nature de ses sous-elements. Trois cas de figure 
peuvent se presenter, lesquels sont detailles au tableau 9-4. 

Tableau 9-4 Representations d'un element complexe par un systeme de fichiers 



Description Representation graphique 


Premier cas : tous les sous-elements ont des contenus complexes. 

L'element vol ume n'est compose que de sous-elements complexes, 
aucun d'eux ne contient directement du texte. lis sont assimilables a 
des dossiers. 

Nous obtenons done une representation arborescente classique, cons- 
titute de dossiers et de sous-dossiers. 


E--Q volume 
El-C] docfront 
El-Q docpart 
El-Q docrear 


Deuxieme cas : au moins un sous-element a un contenu simple, les 
autres ayant un contenu complexe. 

Le sous-element de type simple est assimilable a un fichier, les autres a 
des dossiers. 

Le dossier vol ume contient ici un fichier (il s'agit de I'icone 
fichier.txt) et des sous-dossiers qui represented des sous-ele- 
ments de type complexe. 


El-Q volume 

J^ fichier.txt 
Etl-Q docpart 
El-Q docrear 


Troisieme cas : tous les sous-elements sont de type simple et sont assi- 
milables a des fichiers. 

Le dossier vol ume ne contient que des fichiers. 


B-C 


i volume 
_2J idinfo.txt 
j§] revnum.txt 

■■■||| warnpage.txl 
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Dans le premier cas, l'element vol ume ne contient que des sous-dossiers ; il n'y a 
aucun probleme pour que cet element soit un dossier lui-meme : dans notre termino- 
logie, il s'agit d'un element purement structurel. 

Dans le deuxieme cas, l'element vol ume contient un melange de dossiers et fichiers. 
Nous disons que c'est un element de donnees global, locution vague pour designer une 
situation ou l'objet n'est ni un pur conteneur ni un vrai fichier. 

Dans le troisieme cas, le dossier vol ume ne contient que des fichiers. II pourrait etre 
un fichier lui-meme ; il suffirait pour cela de concatener les trois sous-fichiers. Nous 
disons dans ce cas que l'element est un element de donnees. 

La nature d'un element a contenu complexe depend de ses enfants. C'est eux et eux 
seuls qui conditionnent la nature de l'element, et non ses parents directs ou ses pre- 
decesseurs. 

Cas des elements mixtes 

Le contenu d'un element mixte est un melange de texte et sous-elements. Les repre- 
senter graphiquement selon le modele dossier/fichier est done plus delicat. Ce 
modele est typique du monde des documents ; il constitue une difference majeure 
entre les applications de XML destinees aux bases de donnees et celles destinees a la 
documentation au sens papier. 

Dans le tableau 9-5, nous allons montrer pourquoi ce modele est en complete inade- 
quation avec l'analogie dossier/fichier. Ce cas simple permet met en evidence le 
probleme : le modele mixte fait tout simplement disparaitre la belle logique des pou- 
pees russes. 

Ces representations graphiques montrent clairement que ce modele fait apparaitre un 
amalgame curieux entre le texte, les fichiers et les dossiers, le role de structuration 
hierarchique des dossiers etant perdu et parfois meme tenu par des objets de type 
fichier, les uns et les autres etant meles en un joyeux desordre ! On est loin de la 
representation aisee du debut de ce chapitre. 



Exempl 



Tableau 9-5 Representation des elements mixtes 
e d'element a contenu mixte 



L'exemple utilise ici est celui du cas precedent, auquel on a ajoute les balises b et i pour obtenir un con- 
tenu mixte : 

<p>L'utilitai re <fc»CATSTA</t» est utilise pour traiter des donnees 
statisti ques et comptables sous <bxi>VM</i> et <i>MVS</ix/b>.</p> 

II y a deux representations possibles de ce fragment. 
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Tableau 9-5 Representation des elements mixtes 


Representation graphique par analogie avec un systeme de fichiers 


Prem 


ere representation : on utilise des fichiers dont le nom est independant de celui des elements. 




3 fichier.txt © 






<p>L'uti"litai re 


^\ fichier.txt 




<b>CATSTA</b> 


est utilise pour traiter des donnees 
statistiques et comptables sous 


Qunmnteneur (representant <t») O 




=ii| fichier.txt 




<i>VM</i> 


et 


© 


i|j fichier.txt 




<i>MVS</i> 


</p> 








Cette representation fait apparaitre de graves irregularis dans la structure : presence d'un fragment tex- 
tuel « flottant » (raccroche a rien) a I'interieur d'un dossier (repere ©) et d'un conteneur dont on ne sait ni 
specifier le nom (repere O) ni expliquer comment il peut concretement figurer dans un fichier (repere ©). 


La seconde representation s'appuie sur des dossiers et des fichiers auxquels on fait porter le nom de I'ele- 
ment qu'ils represented : 




dy p.txt 


© 






L'utilitai re 


jlb.txt 




CATSTA 


est utilise pour traiter des donnees 
statistiques et comptables sous 


Ob 


O 




@ i.txt 




VM 


et 


© 


B i.txt 




MVS 


Cette 
(repe 


representation montre que les problemes de la chatne flottan 
re ©) contenu dans le fichier p (repere 0) sont toujours presents. 


e (repere ©) et du conteneur b 
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Cela ne pourrait fonctionner que si Ton savait imbriquer des dossiers dans des 
fichiers, des fichiers dans des fichiers, et stocker du texte directement dans des 
dossiers ! Le seul moyen de realiser physiquement un tel modele logique serait 
d'avoir la possibilite de poser des liens allant de l'interieur du document vers des dos- 
siers qui contiendraient des fichiers... Notre exemple montre a quel point cela serait 
fastidieux a mettre en ceuvre et surtout incoherent pour la redaction d'un tel petit 
texte. Ce modele est en realite tres proche du modele HTML, dont on connait les 
graves lacunes de structuration. 

Souvenons-nous du probleme essentiel mis en evidence avec le modele mixte : dans 
notre exemple, on ne sait pas a quoi raccrocher la chaine de caracteres et (repere ©). 
Ce probleme existe en HTML et c'est uniquement la permissivite des navigateurs 
qui a masque le probleme : ceux-la considerent que toute chaine de caracteres flot- 
tante est par defaut encadree d'un element p de type paragraphe. Si cela est accep- 
table quand il s'agit simplement d'un probleme d'affichage dans un navigateur, 9a ne 
Test plus quand il s'agit d'etre rigoureux sur la structure de l'information, notamment 
eu egard a des bases de donnees. Nous allons voir a quel point ces anomalies peuvent 
provoquer de serieux blocages si la regie de l'element p induit devenait reelle. Appli- 
quee au fragment precedent, cela donnerait : 

<p>L'utilitai re <b»CATSTA</b> est utilise pour traiter des donnees 
statistiques et comptables sous <bxi>VM</i> <p>et</p> <i>MVS</i> 
</b>.</p> 

Et la presence incongrue de cet element p est non seulement absurde mais egalement 
invalide (a moins de faire un modele recursif ou p peut se contenir lui-meme...). 

Ainsi, toute l'information se trouvant a l'interieur d'un element mixte doit etre consi- 
dered comme etant de la donnee non structuree, et l'element lui-meme doit etre un 
element de donnees. 

C'est pour cela que nous disons que la forme en poupees russes du modele XML est 
moins reguliere qu'il n'y parait de prime abord. Dans ce chapitre, nous developpons 
l'idee que, dans un document XML, tous les elements ne sont pas structurellement 
egaux. 

Cas des elements vides 

En XML, les elements vides finissent souvent par avoir un contenu. Par exemple, 
une balise d'appel de figure est remplacee par ladite figure au moment de la composi- 
tion du document. II en est de meme pour toutes les balises formant des references 
croisees. Lors de la composition, elles sont remplacees par du contenu textuel de type 
« voir aussl », « voir page ». II existe de nombreux autres cas de figure. 
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On aime done mieux considerer les elements vides comme des objets prets a recevoir 
potentiellement un contenu plutot que comme des objets nuls. Les elements vides 
sont pour nous des elements de type simple dont le contenu est ramene a un 
ensemble vide : e'est-a-dire des fichiers vides. 

Nous disons que ces elements sont des elements de donnees. 

Ou doit-on mettre les attributs ? 

A ce stade, notre raisonnement n'a pas tenu compte des attributs XML. 

En XML Schema, la presence d'attributs ne fait pas le type d'un element. II n'y a que 
deux types d'elements : simple et complexe. Les elements de type simple ont un con- 
tenu limite a du texte et aucun attribut. Tous les autres sont de type complexe. 

Cela indique que les concepteurs de XML Schema ont voulu rapprocher les elements 
de type simple des attributs. Du point de vue du typage, il n'y a pas de difference 
entre les deux. Du point de vue conceptuel, ecrire <info><date>23/05/59</date></ 
i nfo> revient a ecrire <i nfo date="23/05/59"/>. 

En XML, les attributs sont clairement degages de toute responsabilite structurelle : 
ils sont dans une dimension perpendiculaire a elle. Les attributs sont des proprietes 
placees sur les elements et un ensemble d'attributs forme une fiche de proprietes. 



Particularity de XML Schema Le typage dynamique des elements 

Avec XML Schema, il est possible dans un document XML de specifier a la volee le type d'un element. II 
suffit pour cela d'utiliser sur I'element concerne I'attribut xsi : type : la seule condition est de specifier 
le nom d'un type qui soit un derive valide du type originel de I'element. Ce mecanisme est toutefois trap 
restrictif pour qu'on puisse dire que XML Schema permet d'influer sur le modele de contenu ou type d'un 
element a partir de la valeur d'un attribut. Par exemple, il est strictement impossible de definir des regies 
telles que : « Si la valeur de I'attribut date de I'element achat est superieure a 2002, alors les sous-ele- 
ments autorises sont euros et cents tandis que, si cette meme valeur est inferieure a 2002, les sous-ele- 
ments autorises sont francs et centimes. » 



Dans la suite de ce chapitre, nous allons utiliser de nombreuses representations gra- 
phiques de documents epurees du nom des attributs. Nous irons meme jusqu'a sup- 
primer le nom des elements car, dans le cadre du sujet de ce chapitre, seule la forme 
du document importe. Ainsi, le document que nous fournissons ci-apres sera repre- 
sente par la figure 9-2 et non par la figure 9-1. 
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<pi 1 oteWeb xml ns : xsi ="http : //www . w3 . org/2001/XMLSchema-i nstance" 

xsi :noNamespaceSchemaLocat"ion="sites.xsd"> 
<sites> 
<site unique-id="ID000000"> 

<nom va"lue="Nicolas le Panda"/> 
<i denti f i cati on> 
<coordonnees> 
<position> 
<"longitude value="48.7494"/> 
latitude value="-2 .1108"/> 
</position> 

<a"ltitude va"lue="900"/> 
</coordonnees> 
</i denti f i cati on> 

<photo nom="photo.gif" format="gif "/> 
</site> 
</sites> 
</pi"loteWet» 



Figure 9-1 

Representation graphique 
complete (elements + attributs) 
d'un document XML 



, 



,--~fc f]il(ikjWc;h 
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Ksi:noNamespaceSchemaLoca(tion "sites. xsd" 
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J unique id "ID000000" 
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Figure 9-2 

Representation graphique 
simplified d'un document XML 



6 



Que faire des metadonnees ? 

Comme leur nom l'indique, les metadonnees sont des donnees sur les donnees. Leur 
role est done de qualifier les autres donnees du document. Cela n'a toutefois aucun 
rapport avec le terme de metadonnees utilise dans les bases de donnees. Cette preci- 
sion est importante car XML etant utilise indifferemment dans les deux mondes - 
celui des documents et celui des bases de donnees -, il y a un risque certain de confu- 
sion. Dans le monde des documents, une metadonnee apporte, a la maniere des attri- 
buts, une information qui nest pas limitee a la description du type des autres don- 
nees. II s'agit par exemple d'informations de gestion, de provenance, de statut, etc., 
applicables a tout ou partie d'un document. Dans le monde des bases de donnees, les 
metadonnees indiquent le type des donnees. 

Par exemple, I'element meta de HTML est une metadonnee. II se trouve dans l'ele- 
ment head, autorise en debut de page HTML. Bien que frere de I'element body, 
I'element head contient des donnees descriptives des donnees contenues dans body. 
Dans ce cas particulier, les elements meta forment la fiche de proprietes de I'element 
body : ils qualifient un sous-ensemble complet d'informations. 

D'une facon generale, les metadonnees d'un document XML ont les particularites 
suivantes : 
• Elles qualifient l'ensemble du document XML. A ce titre, les elements contenant 

les metadonnees sont comme des attributs qui s'appliqueraient a la totalite du 

document XML. 
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• Les elements contenant les metadonnees sont generalement reunis sous un meme 
element racine. lis forment un ensemble d'informations assimilable a une fiche 
d'identite qui pourrait servir d'etiquette au document XML et etre stockee a 
l'exterieur du document XML. 

Une consequence tres importante de ces deux points est que les elements porteurs de 
metadonnees doivent etre assimiles, du point de vue structurel, a des attributs. 
Comme eux, on doit considerer qu'ils font partie d'un plan orthogonal a celui de la 
structure. Comme nous le laissons entendre dans le second point susmentionne, les 
metadonnees doivent pouvoir etre indifferemment stockees a l'interieur ou a l'exte- 
rieur du document XML. 

Pour donner des exemples concrets de metadonnees, nous proposons quelques utili- 
sations de la balise meta de HTML : 



<html> 
<head> 
<title>Bash Reference Manual: </title> 

<meta name="description" content="Bash Reference Manual: "> 
<meta name=" keywords" content="Bash Reference Manual : "> 
<meta name="resource-type" content="document"> 
<meta name="distribution" content="global "> 
<meta name="Generator" content="texi2html 1.64"> 
</head > 

<body> 

</body> 



Ou 



encore 



<html xmlns :o="urn :schemas -microsoft-corn: off ice: off ice" 
xml ns : w="u rn : schemas-mi crosof t-com : of f i ce : word" 
xml ns="http : //www . w3 . org/TR/REC-html 40"> 
<head> 
<meta http-equiv=" Content-Type" 

content="text/html ; charset=windows-1252"> 
<meta name="ProgId" content="Word .Document"> 
<meta name="Generator" content="Microsoft Word 9"> 
<meta name="Originator" content="Microsoft Word 9"> 
<link rel="File-List" href=" ./temp_files/filelist.xml "> 
<title>La boite a outils de base</title> 
</head> 
<body> 

</body> 
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Dans ces fragments, les informations portees par la balise meta servent a qualifier le 
corps (body) de la page HTML. Ces metadonnees agissent comme une serie d'attri- 
buts portee par l'element racine html . S'il n'a pas ete precede ainsi, c'est parce que 
l'element racine, comme tout element, ne peut pas porter plusieurs attributs de 
meme nom. Les attributs name et content de la balise meta ne peuvent pas etre 
repetes sur un meme element, fut-il l'element racine. On ne peut done pas faire 
autrement que d'utiliser des elements meta repetes a l'interieur de l'element head. 
Cet ensemble d'information agit comme si toutes ces donnees etaient portees par le 
seul element html. 

Ces donnees representent typiquement une information contenue dans le document, 
mais qui ne devrait pas l'etre ! Nous aurons l'occasion de montrer comment ces 
informations, qui devraient etre stockees a l'exterieur du document, viennent souvent 
perturber la representation ideale d'un document XML par un arbre constitue, dans 
ses premiers niveaux, d'une structure reguliere de dossiers emboites les uns dans les 
autres. Les metadonnees necessaires a la gestion des documents XML perturbent ce 
bel edifice. 

Les elements XML ne sont pas tous structurellement egaux 

Ce qui peut passer ici pour des subtilites est pourtant necessaire a la comprehension de 
la theorie des elements purement structurels. Au terme de cette analyse preliminaire, 
peut-on encore dire que tous les elements XML sont egaux ? La reponse est non. 

En XML, le systeme des poupees russes n'est pas regulier, et nous avons vu que cela 
tient autant de la nature du langage XML que de celle des donnees. 

Non seulement les elements XML sont inegaux sur le plan structurel, mais ils le sont 
aussi sur le plan fonctionnel. Par exemple, une balise de mise en gras joue un role 
important quand il s'agit d'afficher un document (consequence visible), mais cette 
meme balise encadrant un prix n'apporte rien a une application comptable. En con- 
trepartie, les elements qui ont de l'importance pour une application de gestion elec- 
tronique de documents sont ceux qui servent a le gerer : les elements racines, les 
metadonnees... Plus l'element est proche de la donnee et plus son importance est 
grande pour les applications qui la manipulent ; plus il est structurel et plus son role 
devient important pour la gestion de l'information : 

• Les fonctions de gestion (pose de metadonnees, decoupage du document XML, 
workflow...) ne sont applicables qu'aux seuls elements purement structurels. 

• Toute tentative de gestion sur un autre type d'element est vaine. 

La methode exposee dans la suite de ce chapitre aide a decouvrir les elements pure- 
ment structurels d'un schema. Seuls ces elements permettent de decouper un docu- 
ment XML en plusieurs sous-fichiers en vue d'instituer un modele de gestion avec 
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des petits modules independants, comme si le document XML etait decoupe en plu- 
sieurs petits fichiers. Gerer l'information plus finement qu'au seul niveau de 1' ele- 
ment racine est imperatif quand les documents XML deviennent trop gros ou resul- 
tent de l'assemblage de petits morceaux produits en parallele : il nest alors pas 
concevable de se contenter du seul niveau fichier. 



Decouvrir les elements purement structurels 

Regies d' identification 

Cette section presente les regies formelles qui aident a decouvrir les elements pure- 
ment structurels d'un schema XML. 

Dans la recherche des elements purement structurels, il y a deux situations radicale- 
ment differentes : 

• La qualite d'element purement structurel a ete prise en compte au niveau du 
schema par i'ecriture d'un modele adapte, et tous les elements d'un nom donne 
auront cette qualite. 

• La qualite d'element purement structurel ne se devoile que dans les documents 
XML, en fonction du contexte d'utilisation des elements autorises par le schema. 
Ces elements sont instables, tantot purement structurels, tantot simples elements 
de donnees. La methode que nous presentons permet de les identifier. 

Ainsi, les elements purement structurels sont tantot definis formellement par le 
schema et tantot dependant d'aleas d'utilisation. Seules les applications dont les ele- 
ments purement structurels sont clairement definis par les schemas XML permettent 
d'envisager une gestion modulaire saine des donnees. 

Les regies servant a identifier les elements purement structurels utilisent les expres- 
sions deja vues d'element de donnees, element de donnees global et element purement 
structurel, dont voici les definitions formelles : 

• Un element de donnees definit tout element dont le modele de contenu est de type 
simple ou mixte. Tout element qui n'est pas purement structurel est un element de 
donnees. 

• Un element de donnees global est le premier element de donnees rencontre dans une 
branche de l'arbre quand on le lit dans le sens hierarchique de la racine aux feuilles. 

• Un element purement structurel ne contient aucune sequence d'element de donnees 
comme enfant direct. Une sequence est une serie de deux elements ou plus. 
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La qualite d'element purement structurel ne se decrete pas par une definition ; elle se 
decouvre par nettoyage progressif d'un schema en appliquant les six regies declinees ci- 
apres, selon une methode qui sera vue dans une section suivante. Ce n'est qu'une fois ce 
travail d'epuration realise qu'un schema devoile ses elements purement structurels. 

• Regie n° 1 ou regie d'absorption. Tous les elements enfants d'un element de don- 
nees sont eux-memes des elements de donnees. 

• Regie n° 2 ou regie de l'enfant unique. Un element dont le seul enfant est un ele- 
ment de donnees est un element purement structurel. 

• Regie n° 3 ou regie de la promotion. Un element dont les enfants sont tous des 
elements purement structurels ou des elements de donnees globaux est lui-meme 
un element purement structurel. 

• Regie n° 4 ou regie de la mixite. Un element contenant un ensemble melant ele- 
ments de donnees et elements purement structurels ne peut pas etre transforme 
en element purement structurel. Cette regie s'applique quand les connecteurs 
xs:all ou xs: choice sont constitues d'elements de donnees et d'elements pure- 
ment structurels ou quand les enfants d'un element mixte sont purement structu- 
rels. Ce dernier cas rejoint la regie n° 1. 

• Regie n° 5 ou regie de la tutelle. Si un element contient une sequence d'elements 
de donnees et d'elements purement structurels, le seul moyen de transformer cet 
element en element purement structurel est de faire chapeauter tous les elements 
de donnees par un nouvel element. 

• Regie n° 6 ou regie de l'element celibataire. Un element vide est un element de 
donnees. 



Remarque Element de donnees global 

La notion d'element de donnees global n'est interessante que pour mettre en evidence les noeuds hybri- 
des entre donnees et structure. Pour la seule recherche des elements purement structurels, les elements 
de donnees globaux n'apportent rien de particulier par rapport aux simples elements de donnees, et 
d'ailleurs ils n'interviennent pas dans les six regies enoncees. 



Exemples ^application 

Pour illustrer les regies susmentionnees d'identification des elements purement 
structurels, nous allons utiliser une representation graphique sous forme d'arbre d'un 
document XML. 

Pour les raisons expliquees plus haut, l'exemple de la figure 9-3 ne mentionne ni les 
attributs ni le nom des elements. C'est un cas assez particulier puisqu'il ne contient 
aucun element de donnees a proprement parler. Tous les elements sont vides ou con- 
tiennent des sous-elements. Rappelons-nous toutefois que la regie n°6 conduit a 
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considerer les elements vides comme des elements de donnees. Commencons done 
par les mettre en evidence en les grisant (reperes ©, O, ©, © et © de la figure 9-3). 



Figure 9-3 

Exemple de graphe initial 
avant recherche des elements 
purement structured 



• 



piloteWeb © ( j Element avant traitement 




Element de donnees 



( ) identification © ^^B 



photo © 



o 



coordonnees © 



position 



altitude © 



• 



longitude © 



latitude © 



Nous allons appliquer les regies edictees en commencant par les extremites de l'arbre 
les plus eloignees de la racine. 

Appliquons la definition d'un element purement structurel au noeud 0. Ce noeud 
contient deux elements de donnees, il n'est pas purement structurel. Nous le grisons, 
et notre arbre devient celui illustre a la figure 9-4. 

Cet element devient le premier element de donnees global de cette sous-branche. 

Suite a cette modification, on met en evidence que son parent immediat 
(1' element ©) n'est pas purement structurel puisqu'il contient une serie de deux ele- 
ments de donnees, l'un global, l'autre simple. Nous le grisons done a son tour. L'ele- 
ment parent de celui que nous venons de griser, le ©, est le premier element pure- 
ment structurel que nous rencontrons parce qu'il n'a qu'un seul enfant (regie n°2) ; 
cela donne la situation illustree par la figure 9-5. 

Par consequent, nous avons sous 1' element O une serie composee d'un element de 
donnees ©, d'un element purement structurel © et a nouveau d'un element de 
donnees O. La regie n°4 indique que cet element ne peut etre transforme en un ele- 
ment purement structurel. Nous sommes done tenus de considerer que e'est un ele- 
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Figure 9-4 

Graphe apres analyse 
du noeud 7 



piloteWeb © 




^B nom © (" j identification © ^V 



photo 



( J coordonnees ® 



^^A position © ^^A 



altitude © 



^^M longitude © ^^M 



latitude © 



Figure 9-5 

Graphe apres analyse 
du noeud 6 



9*"° P "~™ 



I sites © 
1 Site © 



^|^B Element de donnees 

fV ) Element purement structurel 



^^fc nom © Q V ) identification O ^B photo © 



I coordonnees © 



^^B position © ^^B 



altitude © 



• 



longitude © 



latitude © 
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ment de donnees, et nous le grisons. Nous appliquons alors la regie n°l et grisons 
1'element purement structurel © que nous venons de trouver, puisque nous ne pou- 
vons pas avoir d'element purement structurel sous un element de donnees. On dit 
qu'il est absorbe. 

Le schema resultant est illustre a la figure 9-6. 



Figure 9-6 

Graphe apres analyse 
des noeuds 2 et 4 



. 



piloteWeb © f j Element avant traitement 



sites O 
Site© 



Element de donnees 
Element purement structurel 



© 



I identification © 



I coordonnees © 



• 



photo © 



• 



position i 



altitude © 



s 



longitude © 



latitude © 



Nous pouvons finalement appliquer la regie n°2 a 1'element © et dire qu'il est pure- 
ment structurel, de meme que son parent ©, en vertu de la regie n°3, ce qui donne le 
resultat illustre a la figure finale 9-12. 

Au terme de l'analyse de ce fragment XML, on a pu determiner que seuls les deux 
premiers elements sont purement structurels. Par consequent, le seul endroit possible 
pour decouper ce fragment en modules se situe entre les elements © et ©. En 
d'autres termes, et pour reprendre notre analogie de debut de chapitre, les deux seuls 
elements assimilables a des dossiers sont les elements © et ©, et 1'element O est obli- 
gatoirement du niveau fichier. 



VOCABULAIRE PSE 

L'expression element purement structurel se traduit en anglais par Pure Structural Element, dont le sigle 
est PSE. Nous utiliserons dans la suite de ce chapitre le sigle PSE au lieu de l'expression francaise complete. 
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Figure 9-7 

Graphe apres analyse 
des nceuds et 1 



© 



S~?\ PiloteWeb © (~~^\ Ele 

2 sites O ^^ 

Site ^-^ 



Element avant traitement 



Element de donnees 
Element purement structurel 



I identification O 



I coordonnees © 



I photo © 



^^B position © ^^B 



altitude 



longitude © 



latitude © 



Methode pratique ^application des regies 



S'appuyant sur un cas concret, cette section detaille la methode qu'il convient de 
suivre pour mettre en evidence les elements purement structurels d'un schema. 

Le schema utilise ici comme exemple, connu sous le nom de J2008, a ete concu pour 
un metier bien specifique : celui des equipementiers de l'automobile. Les noms 
donnes aux elements XML sont le reflet de ce metier. Pour mettre en evidence les 
elements purement structurels d'un schema, il n'est cependant nul besoin d'avoir la 
connaissance d'un metier et d'en comprendre le vocabulaire. La methode ne s'appuie 
que sur la forme du modele XML defini par le schema. 

Nous avons commence par retirer du schema toutes les declarations d'attributs et de 
notations, qui ne servent a rien dans la recherche des PSE. 

Le schema que nous utilisons ici comme exemple fait mille six cents lignes. Pour 
trouver les elements purement structurels qu'un modele de ce type contient, il 
n'existe pas d'autre solution que de mettre en oeuvre la methode que nous proposons. 
Sur un schema aussi important, la mise a jour des PSE prend environ une heure. 
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La methode comporte 12 etapes. Pour chacune, nous presentons la regie a appliquer 
et le resultat attendu. 

La methode a ete concue de facon qu'elle soit appliquee manuellement, mais elle 
pourrait aussi bien faire l'objet d'un programme, lequel n'existe pas a ce jour. Pour la 
derouler, nous avons utilise le logiciel XML Spy et un editeur de fichiers ASCII. 

Etape 1. Preparation de I'environnement 

Cette premiere etape consiste a preparer I'environnement de travail. Si vous n'avez 
pas de schema XML mais seulement une DTD, convertissez-la en utilisant la fonc- 
tion Convert DTD/Schema de XML Spy. La methode que nous exposons, bien que 
facile a transposer aux DTD de XML 1.0, n'est expliquee que par rapport a la syn- 
taxe des schemas XML du W3C. Nous recommandons d'utiliser les options de 
XML Spy illustrees a la figure 9-8. 



Figure 9-8 

Options de XML Spy a utiliser 
pour la conversion DTD vers 
XML Schema 



Convert DTD/Schema 



Please choose the representation of 
document type definition: 

DTD/Schema file form at — 

r DTD 

r DCD 

r XML-Data 

C BizTalk Schema 



J?].*] 



OK 



f? ivV3C Schema 



Cancel 



■Represent complex elements as- 
(* Elements 
C Complex types 



Elements which were used once- 
(* Make global defintion 
C Make local definition 



Si vous partez d'une DTD, la conversion en XML Schema ne peut se faire que si 
cette DTD est valide par rapport a XML 1.0, la conversion ne marchant pas pour 
des DTD SGML. 

Tres important : faites des copies de vos DTD et schemas originels. Les etapes que 
nous allons suivre detruisent les fichiers de travail. 
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Etape 2. Supprimer du schema les commentaires et toutes les 
definitions d'attributs ou de notations 

II faut supprimer du schema toutes les unites d'information de type xs : attri bute et 
xs: notation : 

Exemples : Les "lignes suivantes ont ete supprimees de notre schema : 

<xs:notation name="cgm" pub~lic="-//USA-DOD//NOTATION Computer Graphics 

Metafile//EN"/> 

<xs:notation name="cgmbin" public="ISO 8632 :1993//NOTATION Binary 

encoding//EN"/> 

<xs: attri bute name="configgrpSGMLid" type="xs:ID" use="requi red"/> 
<xs: attri bute name="mcseqnbr" type="xs:NMTOKEN" use="requi red"/> 
<xs: attri bute name="bodycabmf rcode" type="xs:NMTOKEN" use="requi red"/> 
<xs: attri bute name="bodycabdesc" type="xs: string" use="requi red"/> 
<xs: attri bute name="nbrofdoors" type="xs :NMTOKEN" use="requi red"/> 



Remarque Si vous partez d'une DTD 

Si vous partez d'une DTD, nous vous recommandons de faire cette suppression avant la conversion de la 
DTD en schema XML. La suppression des commentaires n'est pas obligatoire. 



Etape 3. Creation de trois elements vides, SDE, GDE et PSE 

Cette etape consiste a creer les trois elements dont nous aurons besoin dans les pro- 
chaines etapes : 

• SDE (Simple Data Element), element de donnee ; 

• GDE (Global Data Element), element de donnee global ; 

• PSE (Pure Structural Element), element purement structurel. 

Mettez ces trois definitions en debut de schema, en reprenant les lignes fournies ci- 
apres : 

<xs : schema xml ns : xs="http : //www. w3 . org/2001/XMLSchema" 
el ementFormDef aul t="qual i f i ed"> 
<xs: element name="SDE"> 

<xs : compl exType/> 
</xs:element> 
<xs: element name="GDE"> 

<xs : compl exType/> 
</xs :element> 
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<xs: element name="PSE"> 

<xs : compl exType/> 
</xs:element> 



Etape 4. Remplacement de tous les elements ayant un contenu mixte 
par I'element SDE 

Pour cela, il faut executer la recherche illustree a la figure 9-9. 



Figure 9-9 

Recherche des elements a 
contenu mixte d'un schema 



ES^^^^^^H ?|x| 










Suivant 




Bechercher: |rnixed="true"| 




I - Mot entier uniquernent 


Annuler 




I - Respecter lacasse 







Cette recherche permet de trouver des structures de ce type : 

<xs:element name="Caption"> 
<xs : compl exType mixed="true"> <- 1 'information recherchee 

<xs:choice minOccurs="0" maxOccurs="unbounded"> 

<xs: element ref="Emph"/> 

<xs: element ref="Sub"/> 

<xs: element ref="Sup"/> 

<xs: element ref="Ftnote"/> 

<xs: element ref="Intxref"/> 

<xs:element ref="Figureref "/> 

<xs: element ref="Tableref"/> 

<xs: element ref="Diagref"/> 

<xs: element ref="extxref"/> 

<xs: element ref="Symbol"/> 
</xs:choice> 
</xs : compl exType> 
</xs:element> 

Vous allez maintenant appliquer les modifications suivantes a ces structures : 

1 Supprimez la totalite du contenu compris entre les balises (incluses) 
<xs : compl exType> et </xs : compl exType>. 

2 Faites un remplacement global du nom de I'element concerne (Caption dans 
notre cas) par SDE, comme illustre a la figure 9-10. 
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Figure 9-10 

Remplacement des elements 
mixtes par des SDE 





J?]*] 








Rechercher : ("Caption" 


Suivant 




Remplacer par : "SDE" 

V Mot entier uniquement 

V Respecter la casse 


Remplacer 

Remplacer tout 

Annuler 





Remarque Attention aux guillemets 

II est important d'utiliser systematiquement les guillemets anglais lors de ces remplacements. Sinon, 
vous prenez le risque de remplacer definitivement et de maniere imprevue des chatnes de caracteres, ce 
qui vous obligerait a recommencer le processus au debut. 



Le resultat obtenu pour votre fragment doit etre : 

<xs: element name="SDE"> 
</xs:element> 

Le mot Caption (parce que c'est ici le nom de la balise de notre exemple) doit avoir 
ete remplace dans tous les modeles de contenu ou il etait reference : 

<xs:sequence> 

<xs: element ref="Craphic"/> 

<xs: element ref="SDE" minOccurs="0"/> 

</xs: sequence> 

Vous pouvez des lors supprimer la definition originelle de l'element Capti on, dont 
vous n'avez plus besoin, en supprimant les deux lignes suivantes : 

<xs: element name="SDE"> 
</xs:element> 

Repetez le processus autant de fois qu'il y a de contenus mixtes et faites une sauve- 
garde du fichier a la fin de cette etape. On entend par sauvegarde une veritable copie 
du fichier, pour eviter de devoir recommencer le processus au debut en cas d'erreur 
ulterieure. 
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Etape 5. Remplacement de tous les elements vides par I element SDE 

Cette etape est, dans son principe, identique a la precedente : elle consiste a recher- 
cher les elements vides qui se caracterisent par un type complexe vide. Pour les 
trouver, executez la recherche illustree a la figure 9-11. 



Figure 9-11 

Recherche des types 
complexes vides 



ES^^^^^^^ ?|x| 








Eechercher: |<xs:complexType/>| 

I - Motentier uniquement 
I - Respecter lacasse 


Suivant 








Annuler 









Void un exemple de fragment trouve : 

<xs: element name="Top"icref"> 
<xs:complexType/> <- 1 'information recherchee 

</xs:eiement> 

Comme pour l'etape precedente, la methode consiste a : 

1 Remplacer globalement le nom de l'element vide par SDE ; dans notre exemple, 
il faut remplacer toutes les occurrences de Topi cref par SDE. 

2 Supprimer la definition originelle de l'element. Dans notre exemple, il faut sup- 
primer les trois lignes de la definition de l'element Topi cref . 

Faites de nouveau une sauvegarde du fichier a la fin de cette etape. 



Etape 6. Remplacement de tous les elements simples par l'element SDE 

La procedure est toujours la meme : rechercher les elements de type simple et rem- 
placer les noms des elements trouves par le mot SDE. 

Les definitions d'elements de type simple contiennent les attributs name et type. 
Elles sont de la forme : 



<xs:element name="Sub" type="xs: string"/> 
<xs:element name="Sup" type="xs: string"/> 

Dans cet exemple, il faut faire un remplacement global de Sub et Sup par SDE, puis 
detruire ces definitions. 

Faites une sauvegarde de votre schema a la fin de cette etape. 
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Etape 7. Transformation en GDE des elements dont le modele de 
contenu est une serie d'elements SDE 

II s'agit maintenant de detecter les elements dont le modele de contenu n'est com- 
pose que d'une sequence d'elements SDE. 

II peut s'agir : 

• d'un modele compose d'un element SDE repete n fois, par exemple : 

<xs : compl exType name="VehConf i gVarYrType"> 
<xs:sequence> 
<xs : element ref="SDE" maxOccurs="unbounded"/> 

</xs:sequence> 
</xs : compl exType> 

• d'une sequence d'elements SDE : 



<xs: element name="Para"> 
<xs : compl exType> 
<xs: sequence> 
<xs:element ref="SDE" minOccurs="0"/> 
<xs: element ref="SDE"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 

• d'un choix non repetitif entre des elements SDE 

<xs : el ement name="Engi neMotor"> 
<xs : compl exType> 
<xs:choice> 
<xs: el ement ref="SDE"/> 
<xs: el ement ref="SDE"/> 
</xs :choice> 
</xs : compl exType> 
</xs:element> 

• d'un choix repetitif entre des elements SDE : 

<xs:element name="ListofSIEs"> 
<xs : compl exType> 
<xs: choice maxOccurs="unbounded"> 
<xs: el ement ref="SDE"/> 
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<xs: element ref="SDE"/> 
</xs :choice> 
</xs : compl exType> 
</xs:element> 

Ces elements etant des elements de donnees globaux, il faut les remplacer par autant 
d'elements CDE, puis supprimer, comme precedemment, leurs definitions originelles 
au fur et a mesure que les remplacements sont effectues. 

Faites une sauvegarde de votre schema a la fin de l'operation. 

Etape 8. Transformation en PSE des elements dont le modele de 
contenu est une serie d'elements GDE 

Cette etape consiste a detecter les elements dont le modele de contenu n'est compose 
que d'une sequence d'elements GDE. 

II peut s'agir : 

• d'un element GDE repete n fois : 

<xs : el ement name="Vehi cl eVars"> 
<xs : compl exType> 
<xs:sequence> 
<xs: el ement ref="GDE" maxOccurs="unbounded"/> 

</xs :sequence> 
</xs : compl exType> 
</xs:element> 

• d'une sequence d'elements GDE : 

<xs: el ement name="Para"> 
<xs : compl exType> 
<xs:sequence> 
<xs: el ement ref="GDE"/> 
<xs: el ement ref="GDE"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 



d'un choix entre elements qui sont tous des GDE 



<xs: el ement name="Para"> 
<xs : compl exType> 



Elements purement structurels 

Chapitre 9 



<xs:choice> 

<xs: element ref="CDE"/> 
<xs: element ref="CDE"/> 
</xs:choice> 
</xs : compl exType> 
</xs:element> 

Ces elements etant des elements purement structurels, il faut les remplacer par 
autant d'elements PSE, puis supprimer, comme precedemment, leurs definitions ori- 
ginelles au fur et a mesure que les remplacements sont effectues. 

Faites une sauvegarde de votre schema a la fin de l'operation. 



Remarque PSE : conserver le nom de I'element originel 

Nous recommandons pour les elements PSE de conserver le nom de I'element originel (en ecrivant, par 
exemple, PSE- Para), sans quoi il serait impossible de les retrouver une fois la methode achevee, ce 
qui serait exactement contraire au but recherche. 



Etape 9. Remplacement de tous les elements qui n'ont qu'un seul 
enfant possible 

Ce remplacement depend du type de I'element enfant et de la valeur des indicateurs 
d'occurrences. 

Le tableau 9-6 recense les differents cas de figure et indique, pour chacun, ce par 
quoi il faut remplacer I'element concerne. 



Tableau 9-6 Tableau 9-6. Remplacement 


des elements qui n'ont qu'un seul enfant 


Type de I'element Valeur des indica- Type a donner a I'element parent 
enfant teurs d'occurrences 


SDE 


0,n 


SDE (parce que le pere est potentiellement vide). 


1,n 


GDE 


1,1 


GDE, PSE autorise 


GDE 


0,n 


SDE (parce que le pere est potentiellement vide). 


1,n 


PSE 


1,1 


PSE 


PSE 


0,n 


SDE (parce que le pere est potentiellement vide). 


1,n 


PSE 


1,1 


PSE 
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Etape 10. Remplacement en GDE de tous les connecteurs xsxhoice qui 
contiennent des elements SDE meles a d'autres 

Ne pouvant presager du choix qui sera fait par l'utilisateur du schema, tout element 
dont le modele de contenu est un choix comprenant au moins un element SDE doit 
etre transforme en GDE. C'est la regie n°4 qui s'applique. La presence d'un seul ele- 
ment de donnees dans un choix empeche de declarer 1' element parent comme etant 
purement structurel, meme si tous les autres elements du choix sont des elements 
purement structured ou des elements de donnees globaux. 

D'une maniere generale, on retient l'option minimaliste. Le type de 1' element parent 
est toujours dicte par l'element de moindre qualite structurelle du modele de contenu. 

Le cas des elements n'ayant qu'un seul enfant dans l'instance est aborde a l'etape sui- 
vante. 

Void un exemple : 

<xs: element name="Condit"ion"> 
<xs : compl exType> 
<xs: choice maxOccurs="unbounded"> 

<xs: element ref="GDE"/> 

<xs: element ref="Spec"/> 

<xs: element ref="GDE"/> 

<xs: element ref="GDE"/> 

<xs: element ref="GDE"/> 

<xs: element ref="GDE"/> 

<xs: element ref="GDE"/> 

<xs: element ref="GDE"/> 

<xs:element ref="Paragroup"/> 

<xs: element ref="SDE"/> 

<xs: element ref="GDE"/> 

<xs: element ref="SDE"/> 

<xs: element ref="F"igure"/> 

<xs: element ref="SDE"/> 
</xs :choice> 
</xs : compl exType> 
</xs:element> 

Dans ce modele de contenu, les elements sont pour la plupart de type GDE. Bien qu'il 
reste encore trois elements de type structurel inconnu (Spec, Paragroup et Figure), 
trois elements de type SDE sont presents. Cela suffit pour decider que l'element 
Condition est de type GDE, alors qu'on aurait pu le croire de type PSE. 
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Resultat final 



L' application de cette methode sur le schema J 2008 aboutit au resultat suivant, dans 
lequel ont ete supprimees les definitions inutiles d'elements SDE, GDE et PSE, 
mais ou ont ete conservees toutes les declarations d'elements purement structuraux 
ainsi que les eventuels GDE contenant des PSE : 

<xs : schema xml ns : xs="http : //www. w3 . org/2001/XMLSchema" 
el ementFormDef aul t="qual i f i ed"> 
<xs: element name="PSE-J2008"> 
<xs : compl exType> 
<xs:sequence> 
<xs: element ref="GDE" minOccurs="0"/> 
<xs: element ref="PSE-ServInfoPool " minOccurs="0"/> 
<xs: element ref="PSE-OEMinfo" minOccurs="0"/> 
<xs:element ref="PSE-paths" minOccurs="0"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 

<xs: element name="PSE-OEMinfo"> 
<xs : compl exType> 
<xs:sequence> 
<xs: element ref="GDE" minOccurs="0"/> 
<xs:element ref="PSE-VehicleVars" minOccurs="0"/> 
<xs: element ref="GDE" m"inOccurs="0"/> 
<xs: element ref="GDE" m"inOccurs="0"/> 
<xs: element ref="GDE" minOccurs="0"/> 
<xs: element ref="GDE" m"inOccurs="0"/> 
<xs: element ref="PSE-ConfigVars" minOccurs="0"/> 
<xs: element ref="PSE-ConfigVarYrs" minOccurs="0"/> 
<xs: element ref="PSE-VehConfigVarYrs" minOccurs="0"/> 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
</xs :sequence> 
</xs : compl exType> 
</xs:element> 

<xs: element name="PSE-Tbody"> 
<xs : compl exType> 
<xs:sequence> 

<xs:element ref="PSE-Row" maxOccurs="unbounded"/> 
</xs:sequence> 



GDE" 


minOccurs= 


'0"/> 


GDE" 


minOccurs= 


'0"/> 


GDE" 


minOccurs= 


'0"/> 


GDE" 


minOccurs= 


'0"/> 


GDE" 


minOccurs= 


'0"/> 
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SDE" minOccurs= 


'0" maxOccurs= 


'unbounded"/> 


SDE" minOccurs= 


'0" maxOccurs= 


'unbounded"/> 


GDE" minOccurs= 


■0"/> 




PSE-Tbody"/> 







</xs : compl exType> 
</xs:element> 
<xs: element name="GDE 
<xs : compl exType> 
<xs:sequence> 
<xs: element ref 
<xs: element ref- 
<xs: element ref- 
<xs: element ref; 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 

<xs : el ement name="PSE-Cal 1 out"> 
<xs : compl exType> 
<xs:sequence> 

<xs: el ement ref="GDE"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 
</xs:schema> 

L' element J 2008, racine de ce modele, est un element purement structurel. II semble 
naturel qu'un element racine soit de type PSE, cependant c'est loin d'etre le cas avec 
toutes les DTD, mais aussi les schemas. 

Sur les quatre elements declares directement sous l'element racine D2008, trois sont 
des elements purement structured, mais le premier (Li stof SIEs) ne Test pas. 

La figure 9-12 illustre le premier niveau de l'arbre sous la racine. Elle montre claire- 
ment que les elements SIE et SIEdelete sont deux elements vides, pouvant etre 
repetes de 1 a n fois. C'est pourquoi l'element parent Li stof SIEs n'est qu'un element 
de donnees global. 



Figure 9-12 

Premier niveau de I'arbores- 
cence 



J2008 



^S& 



, ListofSiEs E3— L-^13- 



-;,OEMitiro Ltl 

i*. j 

- -jj, Paths [+] 



,SIE 



.SIEdelete 



1.» 



Elements purement structurels 

Chapitre 9 



L'element OEMi nf o, qui est purement structurel, contient lui-meme quatre sous-ele- 
ments purement structurels (VehicleVars, ConfigVars, ConfigVarYrs, 
VehConfigVarYrs). Quand on etend le sous-arbre sous OEMinfo, on se rend compte 
que les autres elements sont pour la plupart des parents d'elements vides. C'est la 
raison pour laquelle ils ne sont que du niveau GDE, comme le montre le graphe illustre 
a la figure 9-13. 



Figure 9-13 

Structure de la branche 
OEMinfo 



-i Vehicles 



OEMinfo 



SH3H.; 



Vehicle 



(element vide) 



1.™ 



VehicleVars 



VehicleVar 



Platforms 3— (-"vEl— Platform 



s 



1..0O 

I (element vide) 



SucCatgs B— (— — ) =l- SucCatg 1 (element vide) 



1..0O 



ComfigGroups [+] 
ConfigGroupYrs ffl 

ConfigVars g~(— — JEl- 



ConfigVar 



(element vide) 



1..0C 



ConfigVarVrs Ej3- (— *— ) =r- ConfigVarVr [+ [ 

1..0O 

VehConfigVarYrs B- (-~— )3~ VehConfigVarYr |+ | 

1..0O 

;_ . c ° m P° n ?. n ??. E K~~^) = H Component ] ( e | e m e nt vi d e) 

1..0O 

Symptoms Q — [ ■■■ JEl~ Symptom 



n SymptomCats 



'^W 



SymptomCat 



element vide) 

(element vide) 



1..CO 



SuclnfoTypeSubQuals p— (— — ^3— SuclnfoTypeSubQual 
v 

1..0O 

MktAreas B— (— — JEl— MktArea (element vide) 



1..0O 



Etapes de la demarche de modelisation 

Premiere partie 



Dans la figure 9-14, nous allons nous interesser a l'element table dont on va voir 
qu'il a une structure particuliere dans ce schema. Cet element represente un tableau, 
au sens documentaire, compose de rangees, de cellules et de texte dans les cellules. 
En general, les tableaux a destination de la documentation sont des objets dont le 
balisage est tres structurant et l'element tab! e est un element purement structurel. 
Or, ici, les tableaux, comme nous allons le voir, se devoilent comme etant tres irregu- 
liers, utilisant en alternance tous les types d'elements. 



Figure 9-14 
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Le seul element purement structurel de haut niveau est l'element Cal 1 out, parent de 
l'element tab! e. Ce dernier est perturbe par la presence de Ti tl e, un element de 
type SDE place directement sous tab! e, et par la presence d'un choix important d'ele- 
ments de donnees (para, paragroup, verbatim, etc.). II faut descendre jusqu'aux ele- 
ments Tbody et Row pour retrouver des elements purement structurels. 

Nous avons volontairement laisse le modele dans cet etat pour mettre en evidence ses 
caracteristiques. Dans la realite, nous lui aurions applique la regie n°l et l'aurions regu- 
larise. Le seul element purement structurel decouvert au terme de 1' analyse de cette 
sous-branche aurait ete Callout, mais il aurait ete lui-meme absorbe par son parent 
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Fi gu re, qui se revele etre de type GDE ! De ce fait, la qualite d'element purement struc- 
turel de l'element Call out aurait ete perdue et toute la branche des tableaux serait 
devenue indissociable du reste du document. Dans ce schema, le tableau est solidaire 
du reste du document et ne peut etre mis dans un fichier a part (dans l'intention par 
exemple d'en gerer le cycle de vie de maniere differente du reste du document). 

Par rapport a la methode habituelle qui consiste a comprendre le role individuel de 
chaque element, cette analyse par identification des elements purement structurels met 
rapidement en evidence les singularites du schema. II est recommande de commencer 
par s'attacher a comprendre les articulations macroscopiques d'un schema avant de se 
lancer dans une analyse detaillee du role de chaque element. Cela est particulierement 
vrai quand on recoit un schema aussi volumineux que celui pris ici en exemple. 

Pour en terminer avec les particularites du schema que nous venons d'etudier, et 
notamment celle de l'element Call out, dont la singularity est d'etre un element 
purement structurel absorbe, il est legitime de se demander a quoi sert cet element 
qui ajoute un niveau de profondeur dans l'arborescence sans apporter aucune dimen- 
sion structurelle supplemental (puisqu'il est absorbe). Un architecte d'application 
devra poser cette question aux concepteurs du schema pour connaitre la veritable 
raison de son existence. II existe une bonne raison pour faire ainsi la chasse aux ele- 
ments qui ne servent a rien, car les couts de mise en oeuvre et de maintenance des 
schemas sont directement lies au nombre d'elements qu'ils contiennent. 



En resume... 



La methode presentee dans ce chapitre permet : 

• d'analyser un modele de donnees XML sur le plan de sa structure intrinseque ; 

• d'avoir un regard synthetique sur la macrostructure d'un schema XML ; 

• de distinguer les elements entre eux, et de faire la part entre ceux qui sont impor- 
tants pour la gestion et ceux qui sont importants pour decrire les donnees ; 

• de regler un schema de maniere qu'il reste souple dans differentes situations, et 
notamment qu'il puisse etre adapte a differentes contraintes techniques ; 

• d'ecrire un modele adapte a la cinematique d'un systeme d'information. Ecrire un 
modele n'est pas difficile dans le cadre d'une information statique, mais quand il 
s'agit de concevoir un modele pour un systeme ou l'information evolue, est echan- 
gee et transformee en permanence, mieux vaut prendre quelques precautions. 

Apres avoir etudie les possibilites de modularisation des modeles XML eux-memes, 
nous allons, au chapitre suivant, voir les particularites des documents XML qui sont 
des modules. 
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d'information 



Nous allons maintenant aborder un concept important : celui des modules d'infor- 
mation. 

Nous apporterons des reponses, illustrees par des exemples types, aux questions 
suivantes : 

• Qu'est-ce qu'un module ? 

• Comment definir la taille d'un module ? 

• Quelles sont les regies de conception des modules ? 

Les objectifs de la conception en modules d'information sont simples : il s'agit de 
stocker et gerer l'information sous la forme de granules afin de pouvoir reconstruire a 
volonte toute combinaison jugee utile de ces dernieres. Comme il est preferable de ne 
pas dupliquer l'information, ce precede demande un effort consequent de mise en 
oeuvre. 

L'approche modulaire concerne tous les documents XML qui accompagnent des 
produits ayant plusieurs configurations, vendus dans plusieurs pays, avec des 
variantes par pays, voire par client. Ces documents sont tous fabriques a partir d'une 
meme base d'information mais different de par leur contenu ou leur mise en page. II 
peut s'agir de notices techniques, catalogues, manuels d'utilisation, ou encore de con- 
trats d'assurances ou de textes legaux. 
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L'idee de disposer d'un systeme d'information constitue d'unites faciles a reutiliser 
dans differents contextes et autonomes du point de vue de leur gestion est satisfai- 
sante tant du point de vue fonctionnel qu'intellectuel. En effet, le fait de disposer 
d'un mecanisme pour combiner intelligemment, automatiquement et a la volee ces 
modules d'information en fonction de besoins immediats renvoie a une vision du 
monde de l'information facile a apprehender par un esprit humain. 

Concretement cependant, qu'est-ce qu'un module ? Comment le definir ? Quelles 
sont les regies a respecter ? Telles sont les questions abordees dans ce chapitre. 

Concernant le vocabulaire utilise pour designer un module, si ce terme s'impose peu a 
peu, on utilise encore les locutions homonymes d 'unite d'information, granule, informa- 
tion elementaire, et le terme de module lui-meme se decline au travers des expressions 
suivantes : module d'information, module de donnees ou encore module documentaire. 



Definir un module d'information 

Dans le chapitre 3, nous avons vu comment decouvrir les modeles logiques a partir 
de modeles conceptuels de donnees. Ce chapitre prolonge 1' analyse des modules 
d'information en y integrant les specificites propres a XML. 

« lis savent tout et rien de plus » : cela pourrait etre la definition d'un module d'infor- 
mation. 

Plus prosaiquement, selon la definition officielle, un module est « une unite d'infor- 
mation adressable en tant qu'entite », ce qui signifie en clair : 

• Une unite: un module d'information est un ensemble d'informations physique- 
ment delimite, tel un fichier. 

• Une entite : l'unite est reconnaissable par un identifiant unique. 

• Adresser : l'entite est accessible par une adresse physique de type URL ou chemin 
d'acces (on dirait plus simplement : « on sait ou la trouver »). 

Comme unite d'information « adressable en tant qu'entite », un module d'informa- 
tions se doit de satisfaire aux conditions propres interessant les entites analysees et 
leurs regies de gestion, a savoir : 

• etre identifiable sans ambiguite ; 

• etre stocke dans un fichier auquel on peut associer un identifiant unique de res- 
source, ou URI (Unique Ressource Identifier) ; 

• exister temporellement (les changements d'etats subis au cours d'un processus de 
production doivent pouvoir etre parfaitement identifies) ; 
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• etre porteur d'une logique informative autosuffisante (le module doit contenir une 
information significative, non seulement pour les acteurs de son cycle de produc- 
tion, mais encore pour les applications utilisant les donnees qu'il contient) ; 

• etre plein et entier, c'est-a-dire etre reutilisable sans modification de contenu dans 
plusieurs documents XML ; il s'agit d'un principe d'economie encore appele 
mutualisation des composants. 

La definition pratique d'un module se doit d'etre coherente avec les contraintes 
imposees par les processus (workflow) de creation et diffusion du systeme d'informa- 
tion. Le modele XML retenu doit etre en adequation avec les attentes de ce dernier. 

Un module nest pas un extrait quelconque du modele de donnees ; quant a la defini- 
tion de la taille des modules, ce nest pas un simple probleme de decoupage en petits 
morceaux d'un schema XML. 

Creer des modules a la bonne taille 

Larchitecte des modeles XML vise principalement a obtenir le meilleur compromis 
possible entre les niveaux de granularite et l'efficacite fonctionnelle du systeme 
d'information. Nous presentons dans cette section une methode permettant de creer 
des modules « de bonne taille ». 

II ne s'agit pas ici de definir une quelconque longueur physique ou un poids en octets, 
mais une dimension logique permettant de repondre a la question : « Sur quels 
noeuds de l'arbre commencent et se terminent les modules ? » 

Contrairement a ce que Ton pourrait penser, il ne revient pas aux utilisateurs de definir 
la taille logique de leurs modules. Comme nous allons le voir, ce travail de conception 
revient a l'architecte des schemas XML. Dans un systeme d'information, les roles des 
humains, des services et fonctions du systeme - voir l'etape 1 - et les modeles de 
donnees - voir les etapes 2 a 7 - sont lies. Comprendre et maitriser cette interdepen- 
dance est veritablement la cle de voute de tout succes dans la conception ; cle de voute 
qui tient le pont entre modeles physiques de donnees et utilisateurs du systeme. 

La methode que nous mettons en avant rejoint les considerations des urbanistes des 
systemes d'information. II arrive un moment ou les contraintes fonctionnelles doi- 
vent equilibrer celles pesant sur les donnees. On arrive alors a un point d'equilibre 
qui fait que, du moins en theorie, le systeme fonctionne harmonieusement d'un point 
de vue statique : il donne aux fonctions les donnees juste necessaires. 

Toutefois, une troisieme force vient perturber ce bel equilibre : les processus. La 
methode que nous allons decrire tout au long de ce chapitre a pour vocation de 
trouver dans les modeles le point d'equilibre entre donnees, fonctions et processus. 
En fournissant une demarche logique de decoupage de l'information en modules 
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metier, et adaptant les schemas XML en consequence, on repond a la preoccupation 
des urbanistes : trouver l'equilibre statique du systeme et l'etayer si solidement qu'il 
ne soit pas destabilise par les processus. 

Pour creer des modules a la bonne taille, nous allons etudier la representation gra- 
phique d'un schema (voir la figure 10-2) et le parcourir de haut en bas, puis de bas en 
haut, en gardant a l'esprit la theorie des elements purement structurels qui a ete vue 
au chapitre 9. Le nom donne a la methode renvoie a cette lecture verticale d'un 
schema XML : son intitule est en effet « methode d'analyse top-down et bottom-up ». 
Son application permet de tracer une frontiere entre la partie haute de l'arbre et la 
partie basse, et d'obtenir, dans la partie basse, des blocs verticaux paralleles, qui 
deviendront des modules. In fine, elle permet de superposer le modele de donnees au 
modele des roles, ou acteurs d'un processus. 



VOCABULAIRE Modele des roles 

C'est selon le modele des roles qu'on attribue leurs roles aux acteurs identifies d'un workflow. Par exem- 
ple, un meme programme peut extraire une donnee, la transformer, la valider et la remettre dans le sys- 
teme. Cet unique acteur a ici quatre roles differents. Cet exemple fait bien comprendre I'interet d'avoir 
un modele des roles compatible avec le modele de donnees. 



VOCABULAIRE Workflow 

Workflow est desormais un terme courant du jargon franglais de I'informatique, mais en francais-francais 
on doit dire processus. Un processus est une sequence de taches, que I'on peut representer formellement 
de maniere graphique. Dans notre domaine technique, le mot processus designe exclusivement la liste, les 
acteurs et I'ordre des etapes de changements d'etats d'un objet Qu'il s'agisse du mot workflow ou du mot 
processus, ils sont mis a contribution dans differentes expressions telles que processus qualite, processus 
industriel, processus metier, workflow de courrier, workflow des documents techniques... Le mot anglais 
en lui-meme ne signifie pas grand-chose : le dictionnaire Harrap's le traduit par rythme de travail ! 
Un processus est une somme de changements d'etats, lesquels sont provoques par une action humaine 
ou automatisee, realisee par un acteur qui a un role. Cet acteur peut etre un programme ou un humain. 
Un meme acteur peut bien sur jouer plusieurs roles a differents endroits d'un processus et un meme objet 
peut subir plusieurs changements d'etats. Une fois I'etat d'un objet change, une action de suivi peut etre 
specifiee. 



Dans le schema de la figure 10-1, on donne une representation symbolique des liens 
entre processus et donnees d'assemblage. Chaque activite d'un processus utilise les 
fonctions mises a disposition par le systeme pour la manipulation des donnees. Nous 
avons symbolise ces interactions entre donnees et processus par des fleches allant des 
etapes du processus aux donnees concernees. Lenchainement des activites du pro- 
cessus montre l'imbrication des appels des fonctions d'edition ou d'assemblage des 
donnees. Lorsque les schemas ne sont pas concus sous la forme de modules d'infor- 
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mation, eux-memes regroupes a l'aide d'elements d'articulation, chaque action de 
modification touche l'ensemble de la structure arborescente du document. Cela con- 
duit a des systemes applicatifs de type spaghetti ou 1'imbrication entre les donnees et 
les traitements est telle qu'il est impossible de les faire evoluer. 

La methode decrite dans les paragraphes suivants permet, a partir d'une structure 
XML donnee, de faire apparaitre les modules d'information et leurs elements d'arti- 
culation. 



Figure 10-1 

Schema des trois interactions 
entre les etapes d'un processus 
et les ensembles de donnees 




Transformations 



Donnees d'assemblage Donnees de contenu organisees en modules 



Pour illustrer la mise en oeuvre de cette methode, nous avons choisi la norme mili- 
taire americaine 38784c, qui fait partie de l'historique standard CALS (Computer 
aided Acquisition and Logistics Support) de 1988. Un schema 38784c represente un 
document technique potentiellement volumineux (plusieurs milliers de pages) ; c'est 
la raison pour laquelle l'etude de son decoupage logique est necessaire. Nous avons 
choisi un cas issu du monde des documents « papier », considere comme etant plus 
parlant qu'un cas extrait du monde des donnees. La demarche eut toutefois ete la 
meme avec un schema XML oriente donnees. 

La figure 10-2 illustre les premiers niveaux de ce schema, tres classiquement consti- 
tutes d'elements aux noms evocateurs : doc, volume, front, body, rear, chapter, etc. 
La structure du document est composee de trois elements, front, body et rear 
(repere ©), qui se repetent regulierement a differents niveaux. 

Les noeuds intermediaires du schema separent l'element racine doc des elements 
chapter (repere ©). Quand on expose le contenu de l'element chapter, on obtient le 
graphe de la figure 10-3. 
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Figure 10-2 Les premiers niveaux de notre schema exemple 



Figure 10-3 

Le modele de contenu 
de I'element chapter 
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Cette branche fait apparaitre les elements title et paraO qui ne peuvent pas etre 
dissocies des autres : il s'agit d'elements de donnees (voir le chapitre 9) et leur gestion 
separee sous forme de modules n'aurait pas de sens en soi. 

Quant aux elements section qui se trouvent sous I'element chapter, leur nom suffit 
a donner une idee de leur semantique (voir figure 10-4). Une section est, de toute 
evidence, un type d'element qui correspond fonctionnellement a l'idee qu'on peut se 
faire d'un module. 



Figure 10-4 

Le modele de contenu 
de I'element section 
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Cette analogie entre le nom de l'element, sa fonction et un eventuel role de module 
est plus difficile a etablir pour l'element foldsect, dont le nom ne suffit pas pour se 
faire une idee de son type de contenu. Nous sommes done obliges d'exposer son 
modele de contenu, comme illustre a la figure 10-5. On obtient une structure combi- 
nant elements textuels et appels de figures. 



Figure 10-5 
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foldsect 
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Le modele presente ici est tres irregulier : certaines branches permettent d'acceder en 
tres peu d'etapes a des elements de type paragraphe tel para- nous assimilons a ce 
nom generique tous les elements qui sont des conteneurs de texte -, alors que d'autres 
branches sont longues a derouler, comme nous venons de le voir avec le cas de la 
branche de l'element foldsect. Dans ce schema, certaines branches necessitent de 
parcourir une dizaine de noeuds avant d'arriver a un element terminal de type textuel. 

Comme explique precedemment, la methode top-down et bottom-up permet de 
separer cette grande structure en deux parties superieure et inferieure. Dans chaque 
branche de l'arborescence, nous allons faire passer une frontiere, juste au-dessus du 
premier element de la branche de type textuel. 

Appliquee a la structure de l'element chapter, cette methode donne le resultat 
illustre a la figure 10-6. 
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Figure 10-6 
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Le resultat est un arbre decoupe en deux parties. La methode est done differente de 
celle utilisee pour les elements purement structurels, cette derniere aboutissant quant 
a elle a un decoupage en n parties. 

Pour etendre la methode a l'ensemble du schema, depuis l'element doc jusqu'aux pre- 
miers elements de type para, nous allons simplifier le modele et nous affranchir de 
tous les petits elements textuels qu'il contient, de facon a obtenir une representation 
graphique de taille raisonnable. 

Pour cela, nous changeons le nom de tous les elements terminaux de type textuel, 
que nous remplacons par paraO. Les branches contenant a la fois des paraO et des 
sous-elements de donnees globaux sont egalement remplacees par un seul element 
paraO. Cette methode rappelle les regies de la theorie des elements purement struc- 
turels expliquee au chapitre 9. 

Le resultat illustre a la figure 10-7 met en evidence les deux parties fonctionnelles du 
modele etudie. Dans la partie haute, se trouvent les elements qui permettent 
d'assembler les modules. La partie basse regroupe les branches de l'arbre qui vont 
constituer les modules, et qui, pour l'instant, ont tous paraO comme element racine. 

A ce stade de la presentation de la methode, il nous parait important de souligner 
l'importance de la frontiere ainsi etablie entre donnees et traitements, dans la conti- 
nuite de ce que nous avons explique au chapitre 7 sur les differentes couches de pro- 
grammation. 
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Figure 10-7 Frontiere delimitant les parties haute et basse de notre schema exemple 



Les ratines et le feuillage : les deux parties de I'arbre 

Le decoupage que nous venons d'effectuer va beaucoup plus loin que la seule identi- 
fication de modules. II met en evidence deux mondes differents et complementaires : 

• La partie haute represente le monde de 1' assemblage et releve de la gestion de 
contenu, des processus et des traitements. 

• La partie basse represente le monde de la fabrication du contenu et releve du tra- 
vail des redacteurs techniques, auteurs et programmes de production des donnees 
elementaires. 

La nature des systemes informatiques a utiliser dans l'un et l'autre de ces deux mondes 
est tees differente. Dans l'un, on voudra savoir comment la donnee est saisie, recuperee 
ou synthetisee ; c'est le monde de la gestion des donnees. Dans l'autre, on s'interessera 
aux programmes d' assemblage, publication et diffusion avec comme terreau la gestion 
des documents au sens traditionnel de la GED (Gestion electronique de documents). 
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Verifier la nature des elements racines des modules 

Les modules sont des entites qui doivent avoir une vie autonome. lis ne sont ratta- 
ches a un « tout » plus important (en philosophic, on dit a un « englobant ») qu'au 
moment de la publication finale d'un document, d'une page web... Bref, d'un media 
quelconque. 

C'est pourquoi la derniere etape de la methode va consister a controler l'autonomie 
de ces modules. lis doivent etre aises a decrocher du reste de l'arbre. En d'autres 
termes, l'element parent de leur racine doit etre un element purement structurel. De 
cette maniere, on controle que les resultats de l'analyse de la logique informative du 
schema sont coherents avec ceux de l'analyse des processus. L'element purement 
structurel joue ce role de cle de voute dont il etait question dans l'introduction de ce 
chapitre, ou il etait affirme que la methode permettait de trouver le point d'equilibre 
entre donnees, fonctions et processus. 

L'element racine de chaque module doit etre une articulation du schema. C'est une 
regie de base qu'il faut respecter. En effet, si un module est un sous-document inde- 
pendant du document XML principal, il en contient potentiellement toutes les 
variations possibles autorisees par le schema. Garantir que cet element est purement 
structurel revient a garantir son role d'articulation dans tous les cas de figure. 

Quand il apparait que l'element racine d'un module n'est pas un PSE, il faut choisir 
entre aj outer un element parent a cette racine - cela suffit generalement a la trans- 
former en PSE - ou elaguer les branches qui l'empechent d'etre un PSE. Le plus 
souvent, l'element n'est pas un PSE car il est encadre sur sa gauche et/ou sa droite 
d'elements textuels ; c'est le cas des elements chapter et title de la figure 10-3. 

Pour les elements de gauche, il peut s'agir de metadonnees, ou donnees descriptives 
du reste de la branche (un titre, par exemple). Si tel est le cas, on tentera de modifier 
le modele afin que ces donnees deviennent des attributs de la racine du module. 
Ainsi, un titre sous l'element chapter pourrait devenir un attribut de cet element. 
Les donnees de droite doivent etre regroupees quant a elles sous un nouvel element. 
Faute de satisfaire a ces modifications, la cle de voute ne pourra reellement exister et 
le systeme sera toujours bancal. 

Creer les articulations de la structure 

Pour garantir la flexibilite des schemas, il faut y introduire, comme nous l'avons vu, 
des cles de voute. II s'agit d'elements autour desquels s'articulent les differents sous- 
ensembles, sous-arbres et fragments dont on aura besoin dans les sous-systemes et 
qui auront ete definis au terme de la phase d'analyse des processus de production. 
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Nous allons voir de facon concrete dans cette section comment s'ecrivent ces cles de 
voute. 

Comme toute articulation, elles sont en realite composees de deux elements qui 
s'emboitent l'un dans l'autre : Fun est le fils de l'autre. L'ensemble se comporte 
comme un attelage : l'un joue le role d'anneau et l'autre de crochet, comme illustre a 
la figure 10-8. 

Dans la partie droite de la figure, les elements anneaux sont represented en noir et les 
elements crochets en gris. Les anneaux peuvent recevoir plusieurs elements crochets, 
ce qui est le cas de i'element n°3, ou d'autres elements anneaux, comme l'element 
n°2. La fonction de ces elements est de faciliter le decouplage des sous-arbres. 
Quand une telle separation est operee, les elements anneaux deviennent des elements 
terminaux, et les elements crochets les racines des fragments detaches. 



Figure 10-8 

Les articulations, ou cles 
de voute, d'un schema XML 




Les elements anneaux et crochets 
en representation symbolique 




Les elements anneaux et crochets 
dans un schema 



Considerons trois schemas, dont l'un represente la somme des deux autres. Ces 
schemas font intervenir deux elements reellement appeles anneau et crochet pour les 
besoins de notre exemple. Nous allons montrer comment ces elements doivent etre 
definis en XML Schema pour que l'anneau soit un element alternativement de type 
vide ou complexe, et le crochet alternativement racine d'un document XML valide 
ou enfant de l'anneau. 

Lobjectif final n'est evidemment pas de disposer de trois schemas mais de deux, 
complementaires, qui, combines par le jeu des inclusions, en formeront un troisieme. 
Pour la clarte de notre expose, ce troisieme schema sera appele schema global, tandis 
que les deux autres seront appeles schema de l'anneau et schema du crochet. 
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Void le schema de l'anneau : 

<?xml version="1.0" encoding="UTF-8"?> 
<xs : schema xml ns : xs="http : //www. w3 . org/2001/XMLSchema"> 
<xs: element name="meta-structure"> 
<xs : compl exType> 
<xs:sequence> 

<xs: element name="anneau" type="anneauType" ninable="true"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 

<xs : compl exType name="anneauType"> 
<xs : si mpl eContent> 

<xs : extensi on base="xs : stri ng"/> 
</xs : si mpl eContent> 
</xs : compl exType> 
</xs:schema> 

Remarquez que nous sommes obliges de definir 1' element anneau au travers d'un 
type global, en l'occurrence anneauType. Cela nous est impose par les regies de 
XML Schema sur la redefinition, laquelle ne s'applique qu'aux types, qui plus est 
globaux. 

Le schema du crochet : 



<?xml version="1.0" encoding="UTF-8"?> 
<xs : schema xml ns : xs="http : //www. w3 . org/2001/XMLSchema"> 
<xs: element name="crochet"> 
<xs : compl exType> 
<xs:sequence> 

<xs: element name="para" type="xs:string"/> 
</xs :sequence> 
</xs : compl exType> 
</xs:element> 
</xs: schema> 

Ce schema n'a rien de specifique. 
Le schema global : 

<?xml version="1.0" encoding="UTF-8"?> 

<xs : schema xml ns : xs="http : //www. w3 . org/2001/XMLSchema"> 
<xs : i ncl ude schemaLocati on="crochet . xsd"/> 
<xs: redefine schemaLocati on="anneau.xsd"> 
<xs : compl exType name="anneauType"> 
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<xs : compl exContent> 
<xs : extensi on base="anneauType"> 
<xs:sequence> 

<xs:element ref="crochet" maxOccurs="unbounded"/> 
</xs:sequence> 
</xs: extensi on> 
</xs : compl exContent> 
</xs : compl exType> 
</xs: redefine> 
</xs:schema> 

Ce schema contient une inclusion simple, celle du schema du crochet, et une redefi- 
nition, celle du schema de l'anneau. Le schema global est done limite aux seules defi- 
nitions de ses propres elements et aux redefinitions des elements de jointure. 

Nous presentons ci-dessous les documents XML correspondants. 

Document XML de l'anneau : 

<?xml version="1.0" encoding="UTF-8"?> 

<meta- structure xmlns:xs"i=" http://www.w3 . org/2001/XMLSchema- instance" 
xsi :noNamespaceSchemaLocation="anneau.xsd"> 
<anneau/> 
</meta-structure> 

Ce document ne contient qu'un seul element vide anneau et son parent 
meta-structure. 

Document XML du crochet : 

<?xml version="1.0" encoding="UTF-8"?> 

<c rochet xml ns : xsi ="http : //www . w3 . org/2001/XMLSchema-i nstance" 
xsi : noNamespaceSchemaLocati on="crochet . xsd"> 
<para>bl abl a</para> 
</crochet> 

Dans ce document, 1' element crochet est racine. 
Document XML de l'ensemble : 

<?xml version="1.0" encoding="UTF-8"?> 

<meta- structure xml ns: xsi =" http://www.w3 . org/2001/XMLSchema- instance" 
xsi : noNamespaceSchemaLocati on="ensembl e . xsd"> 
<anneau> 
<crochet> 
<para>bl abl a</para> 
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</crochet> 
</anneau> 
</meta-structure> 



Dans une application reelle, l'ideal serait d'utiliser le mecanisme d'inclusion de Xln- 
clude, comme ci-apres : 

<?xml version="1.0" encoding="UTF-8"?> 

<meta- structure xmlns :xsi=" http://www.w3 . org/2001/XMLSchema- instance" 

xsi : noNamespaceSchemaLocation="chap08-anneau-c rochet .xsd"> 
<anneau> 
<xi : "include href="crochet.xml " parse="xm"l " encoding="UTF-8" 
xml ns: xi =" http://www.w3 .org/2001/XInclude/"> 
</anneau> 
</meta-structure> 

Dans cette section, nous avons rappele l'importance qu'il y a a tenir compte des pro- 
cessus de creation, gestion et publication des documents XML pour decouvrir leurs 
elements de structuration et de modularisation. La methode d'analyse qui a ete pre- 
sentee permet d'adapter le schema initial (en general issu de la seule analyse du 
modele conceptuel des donnees) et d'y introduire des elements anneau et crochet qui 
servent de cles de voute des systemes batis sur le concept de modules. 



Regies de conception applicables aux modules 

Une fois les modules identifies et leurs elements racines etablis, quatre regies de pure 
logique s'appliquent : 

• Regie de non-emboitement. Les modules ne doivent pas etre emboites les uns 
dans les autres, mais uniquement juxtaposes. 

• Regie d'applicabilite. Un module ne peut en aucun cas contenir dans son texte 
une information qui serait de nature a modifier ses regies d'assemblage avec 
d'autres modules. 

• Regie de balisage. Les modules traduisent la volonte de reutiliser une meme 
information a plusieurs endroits ; leur balisage doit done etre souple, flexible, 
facilement reutilisable : on dit que le balisage doit etre polymorphe. 

• Regie d'identification des elements. La puissance d'un systeme modulaire tient 
dans les liens qui vont pouvoir etre tisses entre les modules : ces liens doivent 
s'adapter naturellement a toute configuration d'assemblage des modules. 
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Nous expliquons ces regies dans les prochaines sections. Toutefois, il ne s'agit la que 
de recommandations. Libre a vous de ne pas les suivre. Vous trouverez alors peut-etre 
que votre systeme fonctionne ; il sera simplement plus couteux a mettre au point et 
plus difficile a maintenir. 

Regie de non-emboltement 

Cette regie d'apparence simple est difficile a identifier quand on ne la connait pas, et 
la tentation est grande d'autoriser les modules a s'emboiter les uns dans les autres. 
C'est l'erreur la plus frequemment rencontree et la plus grave. Nous allons l'expliquer 
au travers d'un exemple concret. 

Nous reprenons a la figure 10-9 la representation graphique de 1' element chapter. 
La presence du sous-element section donne envie de decouper la branche chapter 
de sorte que les elements section soient des modules (reperes O et ©). Les elements 
figure, chapeautes par l'element purement structurel foldout, sont de bons candi- 
date pour faire des modules (repere O). Par analogie entre section et foldsect, on 
peut envisager de faire un module de l'element foldout (repere ©). Enfin, pour 
eviter le probleme de l'element title sous l'element chapter, on peut decider que 
l'element chapter lui-meme est la racine du module (repere ©). Sur la figure, les 
encadres en pointille representent les modules possibles de l'element chapter. 



Figure 10-9 

Mise en evidence 
des modules envisages 
sur la representation 
graphique d'un schema 



i i i .i] ii-i 

1: 



: l 'j»» I 



£ 



K Hivl 



;>■» 



£ 



ifej; 



^IC^fe 



• t 1 "' i 



I fnldoul II 

...if.... 

|, liguii:] 



U^ 



graphic ,rr 



V 1 r 

\ f verbatim 4 



„ P h| I 



flgtahle I I legend I 
l±l LtT 



Modeles de reference 

Deuxieme partie 



Sur la vue balisee d'un document XML, l'organisation en modules de la figure 10-9 
peut etre representee par la figure 10-10 : 



Figure 10-10 

Mise en evidence 
des modules envisages 
sur la representation 
balisee d'un document XML 



<chapter> 
<title>Ceci est le titre du chapitre</title> 



<section> 






<title>Ceci 


est 


le titre de la section</title> 


<para0>Ceci 


est 


un paragraphe</para0> 


</section> 






<section> 






<title>Ceci 


est 


le titre de la section</title> 


<para0>Ceci 


est 


un paragraphe</para0> 


</section> 






<foldsect> 






<foldout> 






|<f igure> . . 




</f igure> | 


</foldout> 






<foldout> 






|<f igure> . . 




</figure> | 


</foldout> 






<foldout> 






|<f igure> . . 




</figure> | 


</foldout> 






</foldsect> 







</chapter> 



Or, un module ne peut en contenir d'autres ; l'emboitement est interdit. II faut 
choisir entre : 

• conserver le module du niveau chapter et supprimer tous les autres, 

• supprimer le module de niveau chapter et conserver les modules de niveau 
section, 

• supprimer le module de niveau foldsect et ne conserver que les modules de 
niveau figure, 

• conserver le niveau f ol dsect et supprimer les modules de niveau f i gu re, 

• supprimer les modules de niveau foldsect et figure, et creer des modules de 
niveau f ol dout. 

Le decoupage serait alors tel que le presente la figure 10-11. 

La regie de non-emboitement traduit la volonte d'eviter l'utilisation de liens d'inclusion 
entre les modules. Elle pourrait, de ce fait, etre appelee regie de linearisation des appels de 
modules. Elle met en evidence la structure qui formera le squelette d'une publication, que 
nous appelons dans cet ouvrage backbone, meta- structure ou structure d'assemblage. Dans 
notre exemple, les balises composant ce squelette sont chapter et f ol dsect. 
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Figure 10-11 

Decoupage finalement retenu 
apres verification de la regie 
de non-emboTtement 



<chapter> 
<title>Ceci est le titre du chapitre</title> 



<section> 








<title>Ceci 


est 


le 


titre de la section</title> 


<paraO>Ceci 


est 


un 


paragraphe</paraO> 


</section> 








<section> 








<title>Ceci 


est 


le 


titre de la section</title> 


<paraO>Ceci 


est 


un 


paragraphe</paraO> 


</section> 









<f oldsect> 



</foldsect> 
</chapter> 



<foldout> 




<f igure> . . . 


. . . </f igure> 


</foldout> 




<foldout> 




<f igure> . . . 


. . . </f igure> 


</foldout> 




<foldout> 




<f igure> . . . 


. . . </f igure> 


</foldout> 





D'autres effets de bord sont evites par la regie de non-emboitement : l'independance 
des modules facilite leur mise a jour en assurant une gestion des revisions avec des 
interferences limitees entre modules. 



Remarque Element ou attribut ? 

Dans notre exemple, I'element titre, sous chapter, empeche a lui tout seul I'element chapter 
d'etre purement structurel. En I'etat du schema de I'exemple, nous n'aurions done pas pu declarer 
chapter comme etant la racine d'un module. Nous avons prefere ne pas tenir compte de cette conside- 
ration technique qui, en alourdissant I'exemple, aurait nuit a son cote didactique. Ce choix est admissible 
car, de type simple, I'element ti tre peut ici etre assimile a un attribut de I'element chapter. Ce fai- 
sant, chapter redeviendrait un element purement structurel. 



Regie d'applicabilite 

L'applicabilite traduit une relation de dependance entre une donnee et le systeme 
physique auquel elle s'applique. Ainsi, l'equipement d'une voiture s'applique a une 
partie seulement des vehicules d'une gamme. Le plus souvent, l'applicabilite est le 
miroir de la gestion de configuration des materiels documentes. Elle peut toutefois 
traduire d'autres entires tels que la langue, les particularites propres a un pays, un 
contrat, une competence, voire un age... Recemment, des cri teres de visibilite sont 
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venus s'aj outer aux criteres d'applicabilite : la visibilite concerne les conditions selon 
lesquelles une information peut etre consultee et imprimee. 

Les termes applicabilite, configuration et revision ne doivent pas etre confondus. La 
gestion des revisions consiste a gerer les modifications de contenu successives appli- 
quees a un module au cours de sa vie (y compris pendant les differentes etapes de son 
processus de production, ou workflow), tandis que la gestion de configuration con- 
cerne l'ensemble des modules de donnees reunis a un instant et des circonstances 
donnees pour constituer une information de niveau superieur. 

Des exemples classiques d'applicabilite sont : 

• la version du systeme mecanique ou logiciel documente ; 

• le client a qui le systeme est destine ; 

• les creneaux calendaires, du type « du 23.05.1999 au 15.08.1999 et du 20.09.1999 
au 13.12.2000 »; 

• les fuseaux horaires ; 

• les zones geographiques et territoires commerciaux ; 

• les habilitations (« seules les personnes autorisees peuvent lire ce paragraphe ») ; 

• les langues du pays et du systeme, la langue utilisee dans un systeme n'etant pas 
obligatoirement celle de sa documentation ; 

• la localisation et les habitudes culturelles. 

Le plus souvent, les applicability influencent le texte qui est contenu dans un docu- 
ment, par exemple : « Dans le cas des moteurs Benson, le volant moteur dolt etre cale par 
rapport au repere de gauche, tandis que dans le cas des moteurs Logosse c'est celul du milieu 
qui dolt etre utilise. » La portee d'une applicabilite peut etre un mot, une donnee, une 
phrase, un paragraphe, une section, un module. Ici, nous donnons meme un exemple 
pour montrer que le style redactionnel lui-meme peut etre touche par une eventuelle 
gestion des applicabilites. 

En effet, un des objectifs de la gestion des applicabilites est, pour des raisons evi- 
dentes de securite, d'occulter la partie du document XML qui ne concerne pas un 
lecteur dans une situation donnee. Dans notre exemple, un mecanicien ayant declare 
travailler sur du materiel Logosse devrait lire a l'ecran : « Pour caler le volant moteur, 
utlllsez le repere du milieu. » 

Pour obtenir ce resultat, 1' applicabilite est codee dans le document XML : 

• soit au niveau des mots, comme ci-apres : 

<p>Pour caler le volant moteur, utilisez le repere <applnc 
case="Benson">de gauche</applic><applic case="Logosse">du milieu</ 
applio.<p> 
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• soit au niveau des paragraphes, comme ceci : 

<p applic="Benson">Pour caler le volant moteur, utilisez le repere de 

gauche. <p> 

<p app"lic="Logosse">Pour caler le volant moteur, utilisez le repere du 

milieu.<p> 

Les concepteurs des modeles de donnees ont la responsabilite de definir la strategic 
de balisage (utiliser des elements ou des attributs), de specifier les elements porteurs 
des informations d'applicabilite, ainsi que d'etablir la syntaxe d'ecriture des criteres 
d'applicabilite. En effet, si le cas cite en exemple est simple puisqu'il n'existe qu'un 
critere d'applicabilite, que dire de ceux qui combinent configuration d'un systeme, 
numero de version, date et version linguistique... 

La multiplication des criteres d'applicabilite montre rapidement qu'une telle infor- 
mation ne peut rester inconnue du systeme de gestion. La visibilite humaine et infor- 
matique de cette information est une condition sine qua non du bon fonctionnement 
de la gestion de contenu d'un systeme d'information. Les criteres d'applicabilite doi- 
vent etre exposes. 

La regie d'applicabilite proclame qua l'interieur d'un meme module ne sont autori- 
sees que des variations d'applicabilite d'une meme famille, laquelle doit etre visible a 
l'exterieur du module. La definition d'une famille d'applicabilites depend du secteur 
industriel concerne. Dans notre exemple, la famille pourrait etre definie ainsi : 
toutes motorisation , moteurs=(Benson , Logosse), ou encore 107 Diesel tous 
pays toutes versions... Tout depend des habitudes, contraintes et cas reels de la 
profession. Du seul point de vue conceptuel, l'important est de ramener le probleme 
a un jeu d'etiquettes non entrelacees : la famille d'applicabilites doit pouvoir etre 
identifiee par un nom a partir duquel toutes les variantes d'applicabilites locales doi- 
vent pouvoir etre deduites. Par exemple, il serait interdit de declarer qu'un module de 
donnees s' applique aux « 107 Diesel tous pays toutes variantes », et de mentionner a 
l'interieur une exception telle que « sauf version 4B equipee des moteurs Atlas de 1963 ». 

Lapplicabilite generale d'un module de donnees doit pouvoir etre exposee simple- 
ment au niveau des metadonnees de gestion ; elles sont au module ce qu'une API est 
a un programme. II est possible de declarer sous forme de jeux d'etiquettes simples 
que le module s' applique globalement aux modeles de la famille des « 107 Diesel tous 
pays toutes variantes », mais il est impossible de declarer qu'il s' applique aux modeles 
« 107 Diesel tous pays toutes variantes a l'exception du troisieme paragraphe, qui ne 
s'applique pas aux versions 4B equipees des moteurs Atlas de 1963 ». Sans une telle 
regie, on n'en finirait pas d'enumerer toutes les possibilites et combinaisons d'appli- 
cabilites, sans parler de la gestion des revisions, qui deviendrait alors un probleme 
sans solution. 
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Cette regie peut, a elle seule, provoquer une refonte en profondeur du modele de 
donnees, de la traduction en XML de la logique metier et des interfaces d'acces du 
systeme d'information. 



Regie de balisage 



Quand on etudie le balisage d'un module, on est tiraille entre deux contraintes 
antagonistes : 

• utiliser un balisage porteur d'une semantique precise ; 

• assurer la flexibilite du systeme en augmentant les possibilites d'assemblage des 
modules. Pour cela, il faut que le balisage ne provoque aucune collision de valida- 
tion au moment de l'assemblage des modules. 

Le balisage doit done etre a la fois assez precis, puisque par definition proche de la 
donnee et done des applications, et souple pour que tout assemblage d'un module 
avec un autre ne soit pas rejete par le validateur. Ce dernier principe va tres loin si 
Ton estime que n'importe quel module doit pouvoir etre associe, sans contrainte, avec 
n'importe quel autre... y compris si les schemas internes et d'assemblage sont 
differents ! Les principes etudies au chapitre 5 pour arbitrer entre elements ou attri- 
buts pour le passage de la semantique trouvent toute leur application dans la mise en 
place des modules d'information. 

Lapproche modulaire n'a de sens que si cette flexibilite est respectee. II serait reduc- 
teur de disposer de modules qui ne pourraient etre assembles qu'avec leurs sembla- 
bles. La valeur ajoutee d'un systeme de gestion de contenu oriente modules est preci- 
sement de pouvoir disposer d'une veritable base d'informations reutilisables a volonte 
sous differentes formes. 

Dans l'approche modulaire, on ne peut savoir a l'avance et de facon sure quelle place 
occupera un module dans une publication, tantot section, simple paragraphe ou 
encore commentaire en aparte... II n'est done ni souhaitable ni facile de definir un 
balisage trop directif par rapport a l'usage final de l'information qu'il decrit. Au con- 
traire, un balisage polymorphe est tout indique, qui puisse etre adapte aux environne- 
ments dans lesquels les applications vont le plonger. 

Ces considerations nous conduisent a affirmer qu'un module ne doit etre compose 
que d'elements parmi les plus banals qui soient (paragraphes, listes, titres, etc.) et que 
toute son intelligence doit etre stockee dans des attributs. On est alors proche du 
balisage HTML, complete d'un balisage secondaire reduit a quelques balises per- 
mettant de specifier librement la semantique des donnees. 

Dans le domaine des documents XML orientes donnees, on peut aussi obtenir des 
balisages neutres, ou banals, en utilisant des jeux de balises representant principale- 
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merit les associations entre donnees plutot que les donnees elles-memes. C'est ce que 
nous avons fait en reprenant i'exemple du chapitre 2, en figure 2-1, cette fois-ci en 
indiquant que la hierarchie representee graphiquement pouvait se traduire en XML 
soit par un balisage specifique de l'application, soit par un balisage neutre et generique 
inspire de Topic Map. Nous en donnons un exemple concret dans le tableau 10-1. 



Tableau 10-1 Balisage specifique vs 


neutre dans des documents XML orientes donnees 


Balisage specifique a une application 


Balisage neutre inspire de Topic Map 


<artiste nom="Jean"> 




<data classe="artiste" id="pl">3ean 


<troupe nom="Troupe du theatre de 




</data> 


Lyon"/> 




<data classe="troupe" id="tl"> 


<fi"lm_joue nom="grand bleu"/> 




Troupe du theatre de Lyon 


</artiste> 




</data> 

<data classe="fi"lm" id="fl">Le grand 

Bleu</data> 

<"link> 

<source idref="pl" role="acteur"/> 

<target "idref="fl" role="fi~lm"/> 

<arcrole>est acteur du film</arcrole> 

</link> 

<1ink> 

<source idref="pl" role="acteur"/> 

<target idref="tl" role="troupe"/> 

<arcrole>est membre de</arcrole> 

</link> 



Avec l'approche modulaire, la question nest plus de savoir si i'information contenue 
dans le module apparait au debut, a la fin, en haut ou en bas de l'arbre, mais de savoir 
quel sera le sens de parcours du lecteur avant d'arriver a I'information. On n'est plus 
dans un concept hierarchique d'acces a I'information, mais dans une organisation 
neuronale basee sur des liens. On passe ainsi d'une organisation hierarchique a une 
organisation totalement en reseau. 

Le principe du balisage polymorphe traduit la volonte de rendre polymorphes les 
modules eux-memes. Cette regie s' applique egalement aux documents XML orientes 
donnees : il faut refiechir a la porte semantique du balisage qu'ils utilisent ; sans cet 
effort de reflexion sur la semantique du balisage, ce ne serait qu'une pale copie des 
tables relationnelles qu'ils interfacent. 
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Regie de limite inferieure de modularisation 

II se peut que vous soyez tente de creer des modules de tres petite taille sous pretexte 
que telles ou telles donnees (ou phrases) se trouvent reutilisees a l'identique a diffe- 
rents endroits d'un document XML. Or, contrairement a ce que Ton pourrait penser, 
il ne faut pas le faire, en tout cas pas sous la forme de modules. 

Par exemple, la reprise a l'identique d'une meme phrase a differents endroits d'un 
document ha jamais signifie que cette phrase devait faire l'objet d'un module. La 
raison en est simple : sortie de son contexte d'utilisation, cette phrase n'a probablement 
aucun sens ; ce n'est pas une unite logique d'information. Ce qui se comprend simple- 
ment avec le cas d'une phrase se comprend encore plus avec une donnee elementaire, 
telle que 24 ' 5 : sorti de son contexte d'utilisation, ce chiffre ne veut rien dire. 

Ainsi, il y a rupture totale entre les concepts de donnees elementaires et celui d'unite 
d'information ou module. Le processus meme de creation d'une donnee elementaire 
n'a absolument rien a voir avec celui de l'unite d'information qui l'utilise (on devrait 
dire qui l'exploite). On comprend aisement qu'il serait stupide de creer dix modules 
pour les chiffres de a 9 sous pretexte qu'ils sont utilises partout ! Faire cela serait 
evidemment absurde. De meme que tout n'est pas objet, tout n'est pas decomposable 
a 1'infini. 

En clair, il existe reellement une limite inferieure a la decomposition des unites 
d'information. La mutualisation des composants des documents XML ne peut aller 
au-dela d'une certaine limite au risque d'aboutir a un phenomene de surpopulation 
qui provoquerait l'effet inverse a celui recherche : une paralysie complete du systeme 
d'information. 

Cela ne veut pas pour autant dire qu'il n'est pas possible d'etablir des listes ou catalo- 
gues de granules d'information elementaires : des phrases types, des icones types, des 
ensembles de phrases tels que des formules legales standard, sont par exemple de tres 
bons candidats a une mise en bibliotheque d'objets types. Les bibliotheques peuvent 
etre organisees par themes et suivre leur propre cycle de revision/mise a jour. Les 
objets qui s'y trouvent peuvent etre references dans les documents par des expressions 
XPath, XPointer, ou de simples identifiants. En tout etat de cause, ils ne font pas 
l'objet de modules independants ; c'est tout au plus des atomes d'information et seules 
les bibliotheques peuvent pretendre etre considerees comme etant des modules. 

Regie d'identification des elements 

Dans la meme veine que le polymorphisme du balisage, les identifiants de references 
croisees doivent s'adapter en toutes circonstances au resultat de 1' assemblage de 
modules, et ce, sans limitation liee a des contingences physiques. 
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Quand les liens inter-modules sont ecrits en dur (comme la plupart des liens ecrits 
dans les pages HTML), le systeme est rapidement gele. C'est particulierement vrai 
dans l'approche modulaire puisqu'un lien cree une relation de dependance entre 
modules. Cela est contradictoire avec la volonte d'assembler des modules indepen- 
dants au gre des besoins. Si la seule utilisation d'un module obligeait a rapatrier ceux 
qui lui sont lies, c'est de proche en proche potentiellement toute la base qu'il faudrait 
rapatrier, a la maniere d'une pelote de laine dont on commence a tirer le fil. 

Pour preserver la souplesse d'un systeme modulaire, les modules ne doivent contenir 
que des liens logiques dont le nombre est reduit autant que faire se peut : une bonne 
modelisation conduit toujours a creer automatiquement un grand nombre de liens. 

Dans les modules, les sources et cibles de liens doivent etre definis logiquement. La 
valeur concrete d'un lien sera calculee au dernier moment, en fonction du media de 
publication. 

Nous allons expliquer comment s'affranchir dans les modules des liens dits point a 
point, equivalents XML des URL de HTML. La technique que nous proposons est 
d'ailleurs inspiree des URL et repose sur la definition d'un couple compose de l'iden- 
tifiant du module cible et de l'identifiant de l'element cible a l'interieur du module 
cible. Le tableau 10-2 en donne un exemple concret. Cette technique permet ulte- 
rieurement de passer a un niveau plus abstrait de liens. 



Tableau 10-2 Exemple de lien en environnement modulaire 



Module source 



<p>Le principe de 1 'identification consiste a 
considerer que tous les identifiants des elements 
d'un module font parti e d'une f ami lie dont le nom 
est l'identifiant du module. En voici un 
exemple : <ref moduleCode="m456-786" target- 
type="table" target-id="t2" ref- 
type="number">.</p> 

Module cible 

<module id="m456-786" rev-number="2 . 5" 
applic="R4U,R4Z"> 

<table id="t2"> 

<title> 

Exemple typique de referencement d'element en 

environnement modulaire </title>. 

</title> 

</table> 
</module> 



Commentaire 

Dans ce fragment, on specifie via la 
balise ref une reference a un tableau 
se trouvant dans un autre module, a 
savoir celui dont l'identifiant est 
m456-786. 




Commentaire 

Ce fragment est la cible de la reference 
ci-dessus. L'identifiant cible porte par 
l'element table est tres simple, la 
valeur t2 est independante de l'identi- 
fiant id du module, de son applicabi- 
lite applic et de son indice de 
revision rev-number. Ce module est 
contenu dans un fichier dont le nom 
peut etre independant de son i d, par 
exemple 456786 . xml . 
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Au moment de 1' assemblage des modules, les identifiants sont rendus uniques en 
accolant l'identifiant du module a celui de l'element cible. La transformation en lien 
definitif est ensuite tres simple. Elle suit la methode presentee au tableau 10-3 et 
peut etre resumee ainsi : 

1 Premiere transformation : creation d'identifiants uniques. 

2 Deuxieme transformation : deplacement des identifiants uniques nouvellement 
crees vers les elements qui seront les vraies cibles physiques (par exemple, si un 
lien pointe logiquement vers une section d'un document, son lien physique cor- 
respondant pointera fort probablement vers le seul titre de ladite section). 

3 Troisieme et derniere transformation : fabrication des liens physiques dont la 
forme depend du media de restitution de l'information. 

Tableau 10-3 La chatne de transformation des identifiants de references croisees 

Etape 1. Creation des identifiants uniques 

Des identifiants uniques sont calcules. Nos modules initiaux deviennent : 

<p>Le principe de 1 'identification consiste a considerer que tous les 

identifiants des elements d'un module font partie d'une famille dont le nom 

est l'identifiant du module. En voici un exemple :<ref refid="m456-786-t2" 

target-type="table" ref-type="number">.</p> 

<table id="m456-786-t2"> 

<title> 

Exemple typique du referencement d'un element en envi ronnement modulaire 

</title> 



</table> 

Etape 2. Deplacement des identifiants vers les elements porteurs 



Deplacement des identifiants vers les elements visibles apres composition. Dans notre exemple, c'est le titre du 

tableau qui sera visible, pas l'element tabl e. 

<p>Le principe de 1 'identification consiste a considerer que tous les 

identifiants des elements d'un module font partie d'une famille dont le nom 

est celui du module. En voici un exemple : <ref refid="m456-786-t2" 

target-type="table" ref-type="number">.</p> 

<table> 

<title id="m456-786-t2"> 

Exemple typique du referencement d'un element en envi ronnement modulaire 

</title> 

</table> 



= 
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Tableau 10-3 La chame de transformation des identifiants de references croisees 

Etape 3. Transformation physique en fonction du media de sortie 

La derniere etape est le calcul de I'URL ou du renvoi textuel. 

1 er exemple : production d'une URL 

<p>Le principe de 1 'identification consiste a considerer que tous les 
identifiants des elements d'un module font parti e d'une f ami lie dont le nom 
est celui du module. En voici un exemple : <a href=./456786.xml#m456-786-t2>au 
tableau « Exemple typique du referencement d'un element en environnement 
modulaire »</a>.</p> 

2 e exemple : production d'une reference croisee pour une impression. Dans ce cas, on ajoute le texte qui apparaitra 

dans la version imprimee 

<p>Le principe de 1 'identification consiste a considerer que tous les 

identifiants des elements d'un module font parti e d'une f ami lie dont le nom 

est celui du module. En voici un exemple : au tableau <ref refid="m456-786-t2" 

target-format="table-number"> page <ref refid="m456-786-t2" 

target-format="page-number">.</p> 

<table> 

<title id="m456-786-t2"> 

Exemple typique du referencement d'un element en environnement modulaire </ti tl e> 
</table> 



La regie d'identification des elements exige que les identifiants d'elements soient 
independants des publications, des indices de revision et numero de version des 
modules, ainsi que des operations de copier-coller des elements entre les modules ou 
au sein d'un meme module. 



Les structures d'assemblage 

Dans l'approche top-down et bottom-up, la structure d'assemblage est un document 
XML qui traduit la partie haute de l'arbre. 

La figure 10-12 en est un exemple facile a comprendre : on retrouve ici la table des 
matieres logique d'un manuel de maintenance, que Ton presente juste apres sous sa 
forme de squelette d'assemblage XML. 

<manual system="DLPruvot" type="0M" idcode="2169329-100" revision="C" 
subtitle="Preliminary version - for external evaluation prototype 
only"> 
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<heading title=" Introduction'^ 

<heading title="Presentation of the system"> 
<dm>&M1300009 ; </dm> 
<dm>&M1300010;</dm> 
</heading> 

<headi ng ti tl e="Composi ti on"> 
<dm>&M1300011;</dm> 
<dm>&M1300013;</dm> 
</heading> 
<heading title="Description of the components'^ 

<dm>&M1300015;</dm> 
</heading> 
</heading> 
<heading title="Utilisation"> 
<heading title="Examination preparation"> 
<dm>&M6000017 ; </dm> 
<dm>&M6000018 ; </dm> 
<dm>&M6000019 ; </dm> 
</heading> 
</heading> 
<heading title="Maintenance"> 
<heading title="Planned maintenance'^ 
<dm title="Planned maintenance user schedule">&M3200025 ;</dm> 
<dm title="Planned maintenance FE's schedule">&M3200026;</dm> 
</heading> 

<heading title="User's procedure"> 
<dm title="Planned maintenance user procedure start">&M3300027;</dm> 
<dm title="Planned maintenance user procedure end">&M3200028;</dm> 
</heading> 
</heading> 
<heading title="Message description"> 

<dm title="User's error "list">&M3700029;</dm> 
</heading> 
</manual> 

L'element recursif heading definit le positionnement hierarchique des modules dans 
la publication. II traduit les imbrications de volumes, chapitres, sections..., qui com- 
posent toute publication, meme s'il s'agit d'un catalogue ou d'un listing de donnees. 
La fonction de l'attribut ti tl e est double : 

• transmettre un titre au systeme de gestion, 

• qualifier un niveau afin de declencher des evenements particuliers de composition. 

Dans l'exemple presente, nous n'avons fait porter a l'element heading, pour des rai- 
sons evidentes de simplification, aucune metadonnee autre que ti tl e. On pourrait 
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Figure 10-12 

Exemple de structure 
d'assemblage 



Logical Document Viewer -2169329-101 (CI) 



View 



J^ldd_iJdd 



1 * Introduction 

Presentation of the system 
i) M1300009[1][09-DEC-97] 
[D M1 300010 [1.0] [09-DEC-97] 
Composition 

[U M1300011 [1.0][09-DEC-97] 
M1300D13 [1] [09-DEC-97J 
Description of the components 
■-- @ M1300015[1.0][09-DEC-97] 
LJ ,» Utilisation 
l— n* Examination preparation 

i— g M6000017 [1.0] [09-DEC-97] 
[1 M600001£[1.0][09-DEC-97] 
i-- H 161 1 0001 9 [1 .0] [09-OEC-97] 
= * Maintenance 

= * Planned maintenance 

— a« User's schedule 
L- M3200025 [1 .0] [1 2-DEC-97] 

— lj,» Fields engineer's schedule 
■— H M3200026 [1.0] [12-DEC-97] 

— a , • U s e r 's p ro c e d ure 
i — o^ Senovision cart 

■— § M3300027[1.0][12-DEC-97] 
— □.• Stereo static positioner 

'-— g M3300023[1.0][12-DEC-97] 
* Message description 

— \S\ M3700029[1.0][12-DEC-97] 



HUB 



View Document 



Close 



Help 



utiliser tout attribut utile pour transmettre aux applications autant d'informations 
que necessaire. Quand le modele modulaire est bien concu, les attributs sont suffi- 
sants pour transmette aux applications la semantique qui les concerne. 
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Remarque Structure d'assemblage 

La figure 10-12 montre la version XML d'une structure d'assemblage. En regie generale, c'est le systeme 
de gestion qui gere, sous la forme qui lui convient, la structure d'assemblage. 



La figure 10-13 montre la representation graphique du schema XML utilise par 
notre structure d'assemblage, et la figure 10-14 en fournit la representation UML. 
La particularite principale du modele est la recursivite de 1' element heading : le 
modele etant valable pour une grande diversite de cas de figure, le nombre de niveaux 
d'imbrication de cet element nest pas fige. C'est la couche metier qui donnera, lors 
des traitements finaux, son veritable sens, ou semantique, a I'element heading (pour 
respecter la regie de balisage decrite plus haut). 



Figure 10-13 

Representation hierarchique 
du modele d'une structure 
d'assemblage 
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Ce schema est conforme a la regie du polymorphisme : des elements dont les attributs 
portent la semantique structurent les niveaux. La DTD de ce schema est la suivante : 

<!ELEMENT meta-structure (status, heading+)> 

<! ELEMENT status (meta*)> 

<! ELEMENT meta (name, value)> 

<! ELEMENT name (#PCDATA)> 

<! ELEMENT value (#PCDATA)> 

<! ELEMENT heading (title?, subtitle?, acronym?, revision?, 

(heading | dm)*)> 
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ATTLIST heading type (f ront | body | rear | other) "other"> 
ELEMENT dm (title?, filename)> 



ELEMENT title 
ELEMENT filename 
ELEMENT subtitle 
ELEMENT acronym 
ELEMENT revision 



(#PCDATA)> 
(#PCDATA)> 
(#PCDATA)> 

(#PCDATA)> 
(#PCDATA)> 



Figure 10-14 

Diagramme UMLde 

la structure d'assemblage 
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Exemple concret 



Le modele que nous allons prendre comme exemple est une reference historique dans 
le domaine de la modularisation. II s'agit de la norme S1000D, utilisee pour les don- 
nees de maintenance. La norme s'applique autant a des documents qua des donnees. 
A ce titre, elle est naturellement modulaire : les operations de maintenance telles que 
le montage/demontage d'un systeme sont souvent communes a plusieurs appareils. 

Nous verrons dans cette section comment les modeles definis par la norme sont eux- 
memes modularises. En effet, la S1000D ne se contente pas de definir une docu- 
mentation sous la forme de modules d'information, mais est elle-meme constituee de 
modeles decoupes en modules. La modularite est totale. 
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Un module conforme a la S1000D est un document XML qui comporte deux 
parties : l'une contient les donnees de gestion et d'applicabilite du contenu, 1' autre le 
contenu a proprement parler. La specification separe nettement le vocabulaire XML 
destine a la structuration du fonds documentaire de celui destine a sa gestion. 



Identification des modules 

Dans la norme S1000D, un module est defini comme etant « une unite d' information 
autosuffisante, contenant un texte et des illustrations relatifs a la mise en ozuvre et a la 
maintenance d'un aeronef, d'un equipement ou d'un materiel de soutien ». Cette unite 
d'information est realisee de telle maniere quelle puisse etre integree et retrouvee 
dans une base de donnees a partir de son Module Code (DMC ou Data Module 
Code). Cet identifiant est bien plus qu'une simple suite unique de caracteres 
alphabetiques : le DMC est une veritable plaque d'immatriculation du module et tra- 
duit, a lui tout seul, son plan de classement par rapport a la logique des operations de 
maintenance. Le tableau 10-4 decrit la structure d'un identifiant de module : la 
lettre a y represente un caractere alphabetique, 1 un caractere numerique et a un 
caractere alphanumerique. Des exemples reels sont donnes juste apres. 





Tableau 10-4 


Structure lexicale du code d'identification d'un module 


Code 


Format 


Signification du code 


Ml 


era 


Projet 


SDC 


A 


Configuration 


SNS 


oca -1 1 - oca 


Sujet 


DC 


a1 


Numero de I'operation de maintenance concernee 


DCV 


a 


IC 


111 


Type d'information contenue dans le module 


ICV 


a 


ILC 


a 


Localisation de I'operation de maintenance 



Tableau 10-5 Exemples reels de codes d'identification de modules 



Data Module Code Sujet technique Information 


A1-A-21 -23-41 -00A-030A-C 


Prise de conditionnement 


Donnees techniques 


A1-A-21 -23-41 -00A-040A-C 


Prise de conditionnement 


Description physique et fonctionnelle 


A1-A-21 -23-41 -00A-800A-C 


Prise de conditionnement 


Procedures et informations de stockage 


A1-A-21-33-22-00A-030A-D 


Raccord mobile pressurisation radar 


Donnees techniques 


A1-A-21-33-22-00A-040A-D 


Raccord mobile pressurisation radar 


Description physique et fonctionnelle 


A1-A-21-33-22-00A-800A-C 


Raccord mobile pressurisation radar 


Procedures et informations de stockage 
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Tableau 10-5 Exemples reels de codes d'identification de modules 


Data Module Code Sujet technique Information 


A1-A-21-51-11-00A-030A-D Echangeur primaire Donnees techniques 


A1 -A-21-51 -1 1 -00A-040A-D Echangeur primaire Description physique et fonctionnelle 


A1 -A-21 -51-11 -00A-800A-C Echangeur primaire 


Procedures et informations de stockage 


A1 -A-21 -52-1 1 -00A-030A-D Echangeur principal 


Donnees techniques 


A1 -A-21 -52-1 1 -00A-040A-D Echangeur principal 


Description physique et fonctionnelle 


A1 -A-21 -52-1 1 -00A-520A-C Echangeur principal 


Depose 


A1 -A-21 -52-1 1-00A-720A-C Echangeur principal Pose 



La structure XML correspondante montre que l'identifiant est saisi au moyen de 
treize balises XML (l'element dmc et les douze balises qu'il contient) : 



<dmc> 

<avee> 

<model i olB</model "i c> 

<sdc>A</sdc> 

<chapnum>31</chapnum> 

<secti on>l</secti on> 

<subsect>5</subsect> 

<subject>01</subject> 

<di scode>00</di scode> 

<di scodev>A</di scodev> 

<i ncode>520</"i ncode> 

<i ncodev>A</i ncodev> 

<i teml oc>A</i teml oc> 

</avee> 

</dmc> 



Classification des modules 

Chaque module a un contenu dont la structure depend du type de rinformation con- 
tenue. Le tableau 10-6 montre la classification etablie dans le cadre de notre exemple. 

Tableau 10-6 Classification des modules S1000D 



Description 


Chapitres/sections/sous-sections, paragraphes/listes/figures... 


Procedure 


Une serie d'etapes (element step) qui correspondent aux differentes riches a executer lors des 
operations de maintenance telles que montage/demontage. 


Catalogue 
illustre 


Tableaux d'equipements et de composants et figures associees. 
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Tableau 10-6 Classification des modules S1000D 



Manuel de vol 


Une partie descriptive associee a des check-lists. 


Cablage 


Definition des cables et connecteurs electriques. 


Planification 


Liste des procedures de maintenance avec leur periodicite d'execution (ex. vidange tous les 
5000 km) et les potentiels des equipements (limites de vie, stockage. . .). 


Panne 


Succession des actions necessaires au diagnostic d'une panne (si... alors... sinon...). 



On voit ici comment des modules, apres avoir ete identifies structurellement par rap- 
port a une arborescence XML, peuvent encore faire l'objet d'une classification en 
fonction de la nature des informations qu'ils contiendront. 

Structure (('assemblage 

Les structures d'assemblage sont des documents XML qui servent a monter une 
publication : ils specifient l'ordre des modules a assembler et donnent les identifiants 
des modules a utiliser. 

La figure 10-15 montre la structure d'assemblage employee par la S1000D. 

Lelement racine est pm, pour publication module. On remarque que les elements 
idstatus et content sous pm sont exactement les memes que ceux utilises dans tous 
les autres cas de modules S1000D : du point de vue de la gestion, une publication est 
un module comme les autres. 

La branche qui nous interesse particulierement ici est content. Elle joue en effet le 
role d'element purement structurel ; ce dernier est immediatement suivi d'un ele- 
ment repetable et recursif : pmentry. Un tel modele de structure est particulierement 
typique des structures d'assemblage. 



Figure 10-15 

Structure d'assemblage 
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Chaque niveau de la structure d'assemblage possede, a la maniere des tables des 
matieres, son propre titre (l'element title), suivi de quatre possibilites : la reference 
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a un module (refdm), la reference a une autre structure d'assemblage (refpm), un lien 
vers une autre documentation technique (refextp), et enfin l'ouverture d'un sous- 
niveau (pmentry). 

Les modules inclus sont references au moyen de leur code DMC (Data Module Code). 

Nous fournissons enfin un exemple concret de document XML representant une 
structure d'assemblage valide par rapport a ce modele : 

<?xml version="1.0"?> 

<pm xm"lns:xsi="http: //www. w3.org/2001/XMLSchema-instance" 

xsi :noNamespaceSchemaLocation="http://www. sl000d.org/S1000D_2-0/ 
xm"l_schema/pm/pmSchema.xsd" 

xmlns: rdf=" http://www.w3.Org/1999/02/22-rdf-syntax-ns#" 
xm"lns:dc=" http://www.purl .org/dc/elements/1.1/" 
xml ns : xl i nk="http : //www . w3 . org/1999/xl i nk"> 
<idstatus> 

<pmaddres> 
<!-- Code de la structure d'assemblage --> 

<!-- Cela afin de pouvoi r la referencer d'une autre structure 
d'assemblage --> 
<pmc> 
<model i olB</model i c> 
<pmi ssuer>D9460</pmi ssuer> 
<pmnumber>00001</pmnumber> 
<pmvol ume>00</pmvol ume> 
</pmc> 
<!-- Metadonnees de la structure d'assemblage : elle-meme est geree 
comme un module --> 

<pmtitle>List of Applicable Publications - Eurofighter</pmtitle> 
<issno issno="002" type="changed"x/issno> 
<issdate year="2003" month="09" day="04"x/issdate> 
</pmaddres> 
<pmstatus> 
<security class="02"x/security> 
<rpc>C0419</rpc> 

<media type="CD-R0M" code-" DSK: lB-A/LOAP-00-D"x/media> 
<qa> 

<fi rstver type="tabtop"x/fi rstver> 
</qa> 
</pmstatus> 
</idstatus> 
<content> 

<!-- Ouverture d'un niveau assimilable a un niveau de section --> 
<pmentry> 
<!-- Titre de ladite section --> 
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<title>Front Matter</title> 
<refdm> 
<!-- Code d'un module composant la publication --> 
<dmc> 
<avee> 
<model i olB</model i c> 
<sdc>A</sdc> 
<chapnum>00</chapnum> 
<secti on>4</secti on> 
<subsect>0</subsect> 
<subject>00</subject> 
<di scode>00</di scode> 
<di scodev>A</di scodev> 
<i ncode>001</i ncode> 
<i ncodev>A</i ncodev> 
<i teml oc>A</i teml oc> 
</avee> 
</dmc> 

<issno issno="001" type="new"x/issno> 
</refdm> 
<refdm> 
<!-- Code d'un module composant la publication au meme niveau 
hierarchique--> 
<dmc> 

</dmc> 

</refdm> 
</pmentry> 

<!-- Ouverture d'un niveau assimilable a un niveau de section --> 
<pmentry> 
<!-- Titre de ladite section --> 

<ti tl e>Introducti on</ti tl e> 
<!-- Code d'un module composant la publication --> 

</pmentry> 

<!-- Ouverture d'un niveau assimilable a un niveau de section --> 
<pmentry> 

<!-- Ouverture d'un nouveau niveau dans la publication --> 
<pmentry> 



</pmentry> 
</pmentry> 
</content> 
</pm> 
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On y remarquera particulierement les points suivants : 

• La structure d'assemblage est geree comme un module : elle a son propre jeu de 
metadonnees de gestion. 

• Le decoupage de type chapitre/section est assure par une balise recursive 
(pmentry) ; chaque section a son propre titre, autonome et independant de celui 
contenu dans les modules. 

• Chaque module composant la publication est reference non par un lien simple, 
mais par une structure XML de type complexe. 



En resume 



Ce chapitre a permis d'aborder de nombreux points relatifs a la mise en oeuvre du 
concept de publication modulaire. Nous avons montre en particulier : 

• la maniere de definir la taille d'un module d'information, 

• l'importance de la presence de cles de voute dans les schemas, 

• la maniere de decrire dans les schemas XML des elements jouant le role d'arti Di- 
lations, 

• les regies de conception de documents modulaires. 

Les regies que nous venons de passer en revue tiennent a la fois du bon sens et des 
contraintes intrinseques de XML. Nous avons notamment insiste sur les principes et 
regies suivants : 

• Le seul decoupage d'un modele XML au niveau des elements purement structu- 
rels ne suffit pas a determiner la bonne taille des modules. 

• Le decoupage en modules n'est pas un debitage du schema XML. 

• Une publication est le resultat de deux mondes : celui des donnees et celui des 
traitements. 

• Les modules ne doivent pas etre emboites les uns dans les autres. 

• Les criteres d'applicabilite doivent s'exprimer simplement et s'appliquer par 
famille a des modules entiers. 

• Le balisage doit etre polymorphe tant a l'interieur des modules que dans les struc- 
tures d'assemblage. 

• Des regies d'independance et de neutralite s'appliquent aux identifiants qui ser- 
vent aux liens. 

• Les metadonnees sont une interface entre le contenu du module et le systeme qui 
le gere. 
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En passant de la donnee au module, puis a la publication, et en etant capable, grace 
aux regies presentees dans ce chapitre, de hierarchiser ces trois niveaux d'informa- 
tion, on repond en grande partie a l'une des exigences de base de la gestion des con- 
naissances, exprimee ainsi par le professeur Shigehisa Tsuchiya : 

« Bien que les termes donnees, information et connalssance soient souvent pris les uns pour 
les autres, ilexiste une distinction claire entre eux. Quand on donne du sens a la donnee via 
un cadre interpretatif, elle devient information, et quand on lit une information en lui 
donnant du sens via un cadre interpretatif elle devient de la connaissance. » 
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Abordons maintenant le sujet des metadonnees, lesquelles fournissent des informa- 
tions sur la nature des autres donnees. Sur cette question, le cas de XML est particu- 
lierement remarquable. Selon ce que Ton met derriere le vocable de metadonnees, on 
peut reperer au moins trois niveaux concernes dans XML : les niveaux du modele, du 
document, et enfin des donnees contenues a l'interieur du document. 

En XML, les metadonnees sont des informations qui se situent a la fois dans le 
domaine de la gestion et dans celui du contenu. En effet, les metadonnees peuvent 
etre aussi bien utilisees pour typer les documents eux-memes que les donnees qu'ils 
contiennent. 

II est possible de definir son propre jeu de metadonnees, a la maniere de la norme 
S1000D, comme d'utiliser un modele tout fait, tel Dublin Core. Enfin, il existe un 
modele standard generique pour definir des modeles de metadonnees : c'est la 
recommandation RDF du W3C. 

Nous verrons, dans les prochaines sections : 

• les metadonnees definies par le schema XML ; 

• les metadonnees relatives a l'entite document ; 

• les metadonnees contenues dans le corps du document. 
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Metadonnees definies par le schema XML 

Au niveau du modele, et particulierement avec XML Schema, les metadonnees sont 
explicites puisqu'il s'agit des noms des types utilises. On connait ainsi la nature exacte 
des donnees contenues dans les elements et les attributs. Par exemple, le type 
xs : date, ou Fun quelconque de ses derives, indique que la donnee correspondante est 
une date et non une quelconque chaine de caracteres. 

En XML toutefois, la notion de metadonnees ne se limite pas au seul type. II existe 
d'autres informations telles que l'espace de noms auquel appartient la donnee, les 
eventuelles valeurs par defaut, les formes lexicales de base, canonique, logique, etc. 

Voila pourquoi une forme de document XML a ete inventee : le PSVI, pour Post 
Schema Validation Infoset. Elle est constitute du document XML de base, aug- 
mente de toutes les metadonnees issues du schema XML qui lui sert de modele. II ne 
s'agit pas d'une juxtaposition du document XML et de son modele, mais veritable- 
ment d'une symbiose, comme nous allons le voir dans 1' exemple suivant. 

Void un document XML volontairement succinct : 

<?xml version="1.0" encoding="UTF-8"?> 

<maison xmlns :xsi=" http://www.w3 . org/2001/XMLSchema- instance" 
xsi : noNamespaceSchemaLocati on="chapi trell . xsd"> 

<murs>4</murs> 

<toit>un toi t</toi t> 
</mai son> 

et le schema XML qui le valide : 

<?xml version="1.0" encoding="UTF-8"?> 
<xs : schema xml ns : xs="http : //www. w3 . org/2001/XMLSchema" 
el ementFormDef aul t="qual i f i ed"> 
<xs:simpleType name="nonNegativeDecimal "> 
<xs: restriction base="xs: decimal "> 

<xs:minExclusive value="0"/> 
</xs : restriction> 
</xs : si mpl eType> 
<xs: element name="maison"> 
<xs : compl exType> 
<xs:sequence> 
<xs:element name="murs" type="nonNegativeDecimal "/> 
<xs: element name="toit" type="xs :string"/> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 
</xs: schema> 
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Void maintenant le PSVI de ce document XML, dans lequel vous remarquerez que : 

• Le vocabulaire des elements et attributs n'est ni celui du document XML ni celui 
de son schema. C'est un vocabulaire propre a l'expression des metadonnees. 

• Les structures definies par le schema XML ne sont pas explicites. Un PSVI n'est 
pas destine a exprimer tous les modeles de contenu d'un vocabulaire XML ; cela 
reste le role des schemas. 

• Les donnees initiales sont enrichies de celles produites par le parseur, lesquelles 
indiquent les conditions de validite des elements, attributs et donnees : le con- 
texte et le type de validation. 

Une lecture meme rapide d'un PSVI aide a comprendre qu'il est possible d'ecrire un 
programme universel de lecture d'un document XML et de toutes les donnees qui 
l'accompagnent. Cependant, un tel programme serait incapable de recrire le schema 
d'origine, ce n'est pas dans ses attributions. 

Dans l'extrait suivant, nous avons encadre et commente les parties qui nous semblent 
significatives. 

<document xm"lns:xsi=' http://www.w3.org/2001/XMLSchema- in stance' 

xmlns: psv=' http://apache.org/xml/2001/PSVInfosetExtension ' 
xml ns= ' http : //www . w3 . org/2001/05/XMLInf oset ' > 
<characterEncodingScheme>UTF-8</characterEncodingScheme> 
<standalone xsi :nil='true'/> 
<versi on>l . 0</versi on> 
<children> 
<element> 
<namespaceName xsi :nil='true'/> 

<!-- ma i son est 1 'element racine du document XML originel --> 
<1 ocal Name>mai son</l oca! Name> 
<prefix xsi :nil='true'/> 
<attributes> 

<!-- metadonnees de tous les attributs de 1 'element maison --> 
<attribute> 
<namespaceName>http://www.w3 . org/2001/XMLSchema- instance 
</namespaceName> 

<1 ocal Name>noNamespaceSchemaLocati on</l ocal Name> 
<prefix>xsi</prefix> 

<normal i zedVal ue>chapi trell . xsd</normal i zedVal ue> 
<attributeType xsi :nil='true'/> 
<references xsi :nil='true'/> 

<psv : val i dati onAttempted>f ul 1 </psv : val i dati onAttempted> 
<psv : val i dati onContextxnai son</psv : val i dati onContext> 
<psv : val i di ty>val i d</psv : val i di ty> 
<psv : schemaErrorCodex/psv : schemaEr rorCode> 
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<psv : schemaNormal "i zedVal ue>chapi trell . xsd</psv : schemaNormal i zedVal ue> 
<psv : schemaSpeci f i ed>schema</psv : schemaSpeci f i ed> 
<psv : typeDef i ni ti onType>si mpl e</psv : typeDef i ni ti onType> 
<psv : typeDef i ni ti onNamespace>http : //www . w3 . org/2001/XMLSchema 
</psv : typeDef i ni ti onNamespace> 

<psv : typeDef i ni ti onAnonymous>f al se</psv : typeDef i ni ti onAnonymous> 
<psv : typeDef i ni ti onName>anyURI</psv : typeDef i ni ti onName> 
</attribute> 
</attributes> 

<namespaceAttri butes> 
<attribute> 
<namespaceName>http : //www. w3 . org/2000/xml ns/</namespaceName> 
<1 oca! Name>xsi </l ocal Name> 
<prefix>xmlns</prefix> 

<normal i zedVal ue>http : //www. w3 . org/2001/XMLSchema-i n stance 
</normal i zedVal ue> 
<speci f i ed>t rue</speci f i ed> 
<attributeType>CDATA</attributeType> 
<references xsi :nil='true'/> 

<psv : val i dati onAttempted>none</psv : val i dati onAttempted> 
<psv : val i dati onContext>mai son</psv : val i dati onContext> 
<psv : val i di ty>unknown</psv : val i di ty> 
<psv : schemaErrorCodex/psv : schemaErrorCode> 
<psv: schemaNormal i zedVal ue xsi :nil=' true'/> 
<psv : schemaSpeci f i ed>schema</psv : schemaSpeci f i ed> 
</attribute> 

</namespaceAttri butes> 

<psv : val i dati onContextxnai son</psv : val i dati onContext> 

<psv : typeDef i ni ti onType>compl ex</psv : typeDef i ni ti onType> 

<psv: typeDef initionNamespace xsi :nil='true'/> 

<psv : typeDef i ni ti onAnonymous>true</psv : typeDef i ni ti onAnonymous> 

<psv: typeDef initionName xsi :nil='true'/> 

<children> 
<element> 
<namespaceName xsi :nil='true'/> 

<!-- murs est l'un des deux sous-elements de 1 'element man son --> 
<1 ocal Namexnu rs</l ocal Name> 
<prefix xsi :nil=' true'/> 
<attributes/> 
<namespaceAttri butes/> 

<psv : val i dati onContext>mai son</psv : val i dati onContext> 
<psv : typeDef i ni ti onType>si mpl e</psv : typeDef i ni ti onType> 
<psv:typeDefinitionNamespace xsi :nil='true'/> 

<psv : typeDef i ni ti onAnonymous>f al se</psv : typeDef i ni ti onAnonymous> 
<psv : typeDef i ni ti onName>nonNegati veDeci mal </psv : typeDef i ni ti onName> 
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<children> 
</children> 
<i nScopeNamespaces> 
<namespace> 
<pref i x>xml </p ref i x> 

<namespaceName>http://www.w3 .org/XML/1998/namespace</namespaceName> 
</namespace> 
<namespace> 
<prefix>xmlns</prefix> 

<namespaceName>http : //www. w3 . org/2000/xml ns/</namespaceName> 
</namespace> 
<namespace> 
<pref i x>xsi </pref i x> 

<namespaceName>http : //www. w3 . org/2001/XMLSchema-i n stance 
</namespaceName> 
</namespace> 
</i nScopeNamespaces> 

<psv : val i dati onAttempted>f ul 1 </psv : val i dati onAttempted> 
<psv : val i di ty>val i d</psv : val i di ty> 
<psv:schemaErrorCode xsi : nil=' true'/> 

<!-Ici on retrouve le contenu de 1 'element murs --> 
<psv : schemaNormal i zedVal ue>4</psv : schemaNormal i zedVal ue> 
<psv : schemaSpeci f i ed>schema</psv : schemaSpeci f i ed> 
</element> 
<element> 
<namespaceName xsi :nil='true'/> 

<!-Ici on retrouve 1 'element toit --> 
<1 ocal Name>toi t</l ocal Name> 
<prefix xsi :nil='true'/> 
<attributes/> 
<namespaceAttri butes/> 

<psv : val i dati onContextxnai son</psv : val i dati onContext> 
<psv : typeDef i ni ti onType>si mpl e</psv : typeDef i ni ti onType> 
<psv : typeDef i ni ti onNamespace>http : //www . w3 . org/2001/XMLSchema 
</psv : typeDef i ni ti onNamespace > 

<psv : typeDef i ni ti onAnonymous>f al se</psv : typeDef i ni ti onAnonymous> 
<psv : typeDef i ni ti onName>st ri ng</psv : typeDef i ni ti onName> 
<children> 
</children> 
<i nScopeNamespaces> 
<namespace> 
<pref i x>xml </pref i x> 

<namespaceName>http://www.w3 .org/XML/1998/namespace</namespaceName> 
</namespace> 
<namespace> 
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<prefix>xm~lns</prefix> 

<namespaceName>http : //www. w3 . org/2000/xml ns/</namespaceName> 
</namespace> 
<namespace> 
<pref i x>xsi </pref i x> 

<namespaceName>http : //www. w3 . org/2001/XMLSchema-i nstance 
</namespaceName> 
</namespace> 
</i nScopeNamespaces> 

<psv : val i dati onAttempted>f ul 1 </psv : val i dati onAttempted> 
<psv : val i di ty>val i d</psv : val i di ty> 
<psv:schemaErrorCode xsi :nil='true'/> 

<!-Ici on retrouve le contenu de 1 'element toit --> 
<psv : schemaNormal i zedVal ue>un toi t</psv : schemaNormal i zedVal ue> 
<psv : schemaSpeci f i ed>schema</psv : schemaSpeci f i ed> 
</element> 
</children> 
<i nScopeNamespaces> 
<namespace> 
<pref i x>xml </p ref "i x> 

<namespaceName>http://www.w3 .org/XML/1998/namespace</namespaceName> 
</namespace> 
<namespace> 
<prefix>xml ns</prefix> 

<namespaceName>http : //www. w3 . org/2000/xml ns/</namespaceName> 
</namespace> 
<namespace> 
<pref i x>xsi </p ref i x> 

<namespaceName>http://www.w3 .org/2001/XMLSchema-i nstance 
</namespaceName> 
</namespace> 

</\ nScopeNamespaces> 

<psv : val i dati onAttempted>f ul 1 </psv : val i dati onAttempted> 
<psv : val i di ty>val i d</psv : val i di ty> 
<psv:schemaErrorCode xsi :nil='true'/> 
<psv: schemaNormal i zedVal ue xsi :nil='true'/> 
<psv : schemaSpeci f i ed>schema</psv : schemaSpeci f i ed> 
</element> 
</children> 

<documentElement xsi : nil='true'/> 
<notations/> 
<unparsedEntities/> 
<baseURI xsi : nil =' true' /> 

<al 1 Decl arati onsProcessed>t rue</al 1 Decl a rati onsProcessed> 
</document> 
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L'expression des metadonnees via le PSV1 exige un vocabulaire precis, reconnu de 
toutes les applications. Le vocabulaire du PSVI est en effet independant de toute 
specification metier : il ne fait que fournir des informations par rapport au seul 
monde XML. Dans les sections suivantes, nous verrons comment en affiner les pos- 
sibility afin de transmettre des metadonnees de maniere concise. 



Metadonnees relatives a l'entite document 

Certaines metadonnees apportent des informations sur le document en tant 
qu'entite. Celles-la ont done pour vocation essentielle de servir a gerer le document 
XML en tant qu'enveloppe. 

Le vocabulaire utilise pour transmettre ces metadonnees peut etre : 

• specifique (nous verrons le cas de la norme metier S1000D), 

• generique (un exemple typique est celui de HTML), 

• commun (nous verrons le cas du Dublin Core), 

• sophistique (nous presenterons RDF). 

Au travers d'exemples pratiques, nous allons etudier ces differents cas de figure. 

Metadonnees specif iques d'une application metier : cas de la S1000D 

Le cas de la norme S1000D a ete introduit au chapitre 8. Nous avons en particulier 
explique comment cette norme definissait plus d'une quinzaine de modeles a partir 
d'un ensemble de schemas generiques combinables. Nous avons notamment montre 
que le meta-modele logique de la S1000D etait organise autour de trois couches de 
schemas. Cette organisation etait representee schematiquement a la figure 8-1. 

Les schemas du niveau de la couche sont communs a tous les modeles. C'est dans 
cette couche que se trouve le modele definissant les metadonnees des modules de la 
S1000D. Remarquant cela, on en deduit que les concepteurs de la S1000D ont sou- 
haite que tous les modules puissent etre geres dans un seul et meme systeme de 
gestion : ce n'est pas un mal ! 

La structure definie pour les metadonnees est composee uniquement d'elements et 
de quelques attributs XML specifiques a i'application S1000D. Elle est representee a 
la figure 11-1. 

Le modele montre que ses metadonnees (idstatus) sont nettement separees du con- 
tenu meme du module (qui est entierement compris dans i'element content) auquel 
elles servent, en quelque sorte, de prologue. 
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Figure 11-1 
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Les metadonnees elles-memes sont constitutes de deux parties distinctes. L'une, 
dmaddres, contient le code d'identification du module (element dmc comme data 
module code), son titre externe (element dmti tl e), ses numero et date d'edition (i ssno 
et issdate). L'autre, status, renferme des informations generates de gestion et de 
controle (dont celles concernant la taille du module, son statut editorial et son emet- 
teur), ainsi que les criteres de son applicabilite qui, dans notre cas present, peut etre 
un modele d'avion (appl i c-a) ou d'equipement (appl i c-e). 

Bien qu'initialement prevu pour les seuls avions militaires, ce modele a inspire de 
nombreux concepteurs de schemas XML. 

Void par exemple une instance reelle de ce modele : 

<?xml version="1.0" encoding="utf-8"?> 

<!DOCTYPE dmodule PUBLIC "-//Aecma//DTD Aecma 1000D Procedural 

20010401//EN" "procedx.dtd" []> 

<dmodu1e> 

<idstatus> 

<!-- Partie identification --> 
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<dmaddres> 

<dmc> 

<avee> 

<!-- Identification du module --> 

<model i olB</model i c><sdc>A</sdc><chapnum>31</chapnumxsecti on>l 

</section> 

<subsect>6</subsectxsubject>00</subjectxdi scode>00</di scode> 

<di scodev>A</di scodevxi ncode>040</i ncodexi ncodev>A</i ncodev> 

<i teml oc>A</i teml oc> 

</avee> 

</dmc> 

<!-- Titres du module --> 

<dmtitle> 

<techname>Multi function Head Down Display, LH</techname> 

<infoname>Remove Procedures</infoname> 

</dmtitle> 

<!-Numero et date d'emission --> 

<issno issno="004" type="changed"/> 

<issdate year="2001" month="05" day="31"/> 

</dmaddres> 

<!-- Partie status --> 

<status> 

<security class="l"/> 

<dmsize>4 Pages</dmsize> 

<rpc>I9005</rpc> 

<orig>Mikel .Kel</orig> 

<applic-a> 

<systemid> 
<version versid=" VER " from="l" to="2"/> 

</systemid> 

<config> 
<mod modtyp="prandpo" modnb="module-number" modcond="engmod"/> 

</config> 
</applic-a> 
<techstd> 

<authbl kx/authbl k> 
<authexx/authex> 
<notesx/notes> 
</techstd> 
<qaxunveri f/x/qa> 
<sbc>XlBA311501000</sbc> 
<skill skill="b"/> 
<remarks>None</remarks> 
</status> 
</idstatus> 
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Lidentification du module repose sur un element de type complexe, 1' element dmc, 
un titre dmtitle constitue d'un sujet (techname) et d'une description en clair du type 
de l'information contenue dans le module (infoname). Dans notre exemple, ce type 
est une procedure de demontage. 

Dans les informations generales de gestion, on releve la presence des elements 
security, orig et rpc qui contiennent respectivement le niveau de confidentialite du 
module et les identifiants des personnes morales responsables de la redaction du 
module et de sa fourniture. 

Lapplicabilite est geree par 1' element appl i c. Nous avons consacre une section du 
chapitre 10 a ce sujet. 

On remarquera enfin les elements relatifs a la qualite qa, aux liens qui sont une parti- 
cularite de l'arborescence physique ou fonctionnelle du systeme documente (les ele- 
ments sbc et fie representent respectivement le code de decomposition systeme, ou 
system breakdown code, et le code d'item fonctionnel ou Functional Item Code). On y 
trouve egalement les niveaux de qualification requis pour executer la procedure (ele- 
ment skill) ou encore relatifs aux raisons qui ont provoque la revision du module 
(element rf u qui signifie reason for update). On notera qu'en ce qui concerne la qua- 
lite, le contenu de l'element qa est impose par un mecanisme de choix entre deux ele- 
ments vides : verif (« le module a ete verifie ») et unverif (« le module n'a pas ete 
verifie »). Point de liberte d'ecriture a ce niveau : l'auteur du module doit choisir Fun 
ou l'autre de ces deux elements. 

Que faut-il en conclure ? 

Ces metadonnees appartiennent a quatre categories differentes : 

• La categorie des metadonnees de rangement du module : son data module code qui, 
remarquons-le, est une structure complexe calquee sur une decomposition plus 
generale (metier) du systeme documente. 

• La categorie des metadonnees de description generale du contenu du module : son 
titre externe (pour le retrouver par son titre) et la nature de l'information qu'il 
contient. 

• La categorie des informations de gestion, ou metadonnees de gestion : numero de 
revision, date d'edition, emetteur, statut editorial. 

• Enfin la categorie des informations destinees aux utilisateurs, ou metadonnees 
applicatives : applicabilite, niveau de confidentialite, taille du module en nombre 
de pages. 

On peut dire que ces categories sont bien representatives des metadonnees qui 
devront le plus souvent etre prises en compte. 
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Metadonnees specifiques d'un media particulier : cas de xHTML 

Le cas de xHTML est interessant a double titre : d'une part, la structure dediee aux 
metadonnees est des plus simples et d'autre part, le probleme de la recherche de 
pages Web est a l'origine de plusieurs travaux sur les metadonnees. C'est en effet en 
vue de rendre la recherche de page Web plus efficace que les Dublin Core et autres 
normes RDF sont etudiees. 

Dans cette section, nous allons etudier le mecanisme de base de xHTML concernant 
les metadonnees. 

Dans les pages xHTML, c'est simple, il n'existe qu'un seul element pour declarer des 
metadonnees : c'est 1' element meta. II est certes normalise, mais de telle maniere que 
l'utilisateur est totalement libre de faire passer la semantique qu'il veut. Cet element est 
equipe de deux attributs : Fun de nom name et 1' autre de nom content. Le premier sert 
a transmettre a l'application un nom de metadonnee et l'autre sa valeur. On peut ainsi 
creer autant de couples (nom,val eur) que necessaire a partir du seul element meta. 

Dans l'exemple de la figure 11-2, nous donnons une representation du debut d'un 
document xHTML dans lequel : 

• On repere facilement l'element meta. 

• La feuille de styles utilisee presente le contenu des attributs name et content 
comme s'il s'agissait de texte normal. 



Figure 11-2 

Exemples de metadonnees 
dans I'en-tete d'un document 
xHTML 



Html ) IhbsiJ S 



?^>DMC: M3562-56<^L 



^Disclosure Level: Confidential'vi^fJ 
I>Subject: ML Project<^] 



^^Miscellaneous: icnref=g3c905-02-l ,eps ; 



i. . 



figref=m3c905-02-g3c905-02-lK^J 
^Document Type: User's ManuaK^lJ 
I>Regions: US<^*EI 
I>System id: 346-v5<^] 



^l^Author: B. Estrade'x^lJ 



^l^Author Date: 2004-05-1 Q<J^ 



<~, 



^l^Reviewer: B. DeschampC^J 



^l>Review Date: 2004-05-20<]^D 
^i>Approval: R. CatrixC^] 
^>Approval Date: 2004-05-20<^] 
^i^Revision number: 8.3 < **&> I 



< ^Head | 
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Void la forme XML de cet exemple : 

<htm"l> 

<head> 

<title> ML project</title> 

<meta name="DMC" content="M3562-56"/> 

<meta name="Disclosure Level" content="Confidential "/> 

<meta name="Subject" content="ML project"/> 

<meta name="Miscellaneous" 

content="icnref=g3c905-02-l.eps;figref=m3c905-02-g3c905-02-l"/> 
<meta name="Document Type" content="User 's Manual "/> 
<meta name="Region" content="US"/> 
<meta name="System id" content="346-v5"/> 
<meta name="Author" content="B. Estrade"/> 
<meta name="reviewer" content="B. Deschamps"/> 
<meta name=" review Date" content="2004-05-20"/> 
<meta name="Approval " content="R. Catrix"/> 
<meta name="Approval Date" content="2004-05-20"/> 
<meta name="Revision number" content="8. 3"/> 
</head> 

Cette approche presente les avantages suivants : 

• Simplicite de mise en oeuvre. 

• Ouverture : il n'y a aucune limite et aucune contrainte dans le choix des noms de 
metadonnees. 

• Compatibilite HTML : quand un tel modele est utilise dans un document XML, 
sa transposition en HTML est des plus simples. 

Inconvenients : 

• La structure de l'element meta est plate, ce qui ne permet pas d'avoir une grande 
precision : il nest pas possible de grouper les metadonnees en paquets logiques. 

• II n'est pas possible d'etablir des liens entre les metadonnees. 

• II n'est pas (ou difficilement) possible de controler les mots utilises comme valeur 
des metadonnees : des erreurs peuvent se glisser lors de leur saisie. 

• II n'est pas possible de specifier le type de l'attribut content : ce ne peut etre 
qu'une chaine de caracteres quelconque. 

Que faut-il en conclure ? 

Ce modele est souple, flexible, immediatement operationnel, et pourra a ce titre 
satisfaire de nombreux besoins. Le manque de controle est son principal probleme. 
Ainsi, ce modele est insuffisant pour ceux qui doivent manipuler des informations 
sensibles comme c'est le cas avec la S1000D. 
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Nous verrons dans la section suivante un modele intermediate qui a l'avantage de 
definir un vocabulaire de base : le Dublin Core. Plus avant dans ce chapitre, nous 
traiterons d'un modele tres sophistique avec le modele RDF : ce dernier ne propose 
ni vocabulaire ni structure predefinie, mais offre des mecanismes pour definir une 
structure et un vocabulaire. 

Metadonnees definies par le Dublin Core 

Le Dublin Core est compose d'un ensemble fini d'elements dont la semantique a ete 
etablie une fois pour toutes. 



Vocabulaire Dublin Core 

Le Dublin Core se denomme ainsi parce que la premiere reunion du groupe de travail sur le sujet se tint a 
Dublin. C'etait en 1 995. Le groupe de travail, quant a lui, fut constitue en octobre 1 994. 



Des la creation du groupe de travail sur Dublin Core, les objectifs etaient de mettre 
en place un modele ameliorant les possibilites de recherche d'information sur le Web. 
C'etait en 1994 et le Web naissait a peine ! 

Les elements du Dublin Core expriment directement la semantique des metadon- 
nees alors que ceux de modeles plus sophistiques, tels que RDF qui sera vu dans une 
prochaine section, traitent des aspects structuraux des descripteurs (ce qui revient a 
codifier la semantique des ressources identifiees par les descripteurs). En d'autres 
termes, Dublin Core est un vocabulaire fige et fini de noms d'elements, tandis que 
RDF permet de creer son propre vocabulaire d'elements et d'attributs. 

Le Dublin Core definit un jeu de 15 elements pour identifier une information. II est 
largement utilise dans le monde editorial et a ete retenu pour une partie des meta- 
donnees de la S1000D (pour celle qui est compatible avec lui bien evidemment). Les 
metadonnees de la S1000D concernees par DC (acronyme usuel de Dublin Core) 
sont celles contenues dans les elements identification et status. 

Une consequence immediate en est que toute application mettant en oeuvre 
Dublin Core pourra classer et gerer a minima les modules ainsi caracterises. 

Nous presentons au tableau 11-1 les 15 elements du Dublin Core et faisons suivre ce 
tableau d'un exemple concret de mise en ceuvre. 

Tableau 11-1 Elements de base du Dublin Core et leur signification 



Elements 


Signification 


<dc:title> 


Titre donne a la ressource pour la reconnaitre. 


<dc:creator> 


Personne physique ou morale responsable de la fabrication du contenu de la ressource. 
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Elements 

<dc:subject> 



<dc:description> 
<dc:publisher> 



<dc:contributor> 



<dc:date> 



<dc:type> 



<dc:format> 
<dc:identifier> 



<dc:source> 



<dc:language> 



<dc:relation> 
<dc:coverage> 



<dc:rights> 



Tableau 11-1 Elements de base du Dublin Core et leur signification 

Signification 

Une phrase, des mots-cles, un code de classification ou toute autre donnee textuelle aidant a 
decrire le sujet du contenu de la ressource. 



Un resume, une table des matieres, une reference a une representation graphique ou toute 
autre forme de description textuelle du contenu de la ressource. 



Personne physique ou morale en charge de I'edition (mise en forme et diffusion) de la ressource. 



Personne physique ou morale qui contribue a la fabrication du contenu de la ressource. 

Une date qui est generalement la date de creation ou de publication de la ressource. II est 
recommande que cette date suive le format YYYY-MM-DD defini dans le profil 
ISO 8601 [W3CDTF]. 



La nature ou le genre du contenu de la ressource. En general, il est recommande ici d'utiliser les 
mots d'un vocabulaire de classification reconnu. 



Le format du support physique associe a la ressource. II est recommande d'utiliser des termes 
reconnus tels ceux de la liste des types de medias Internet ou MIME. 

Identifiant unique (dans un certain contexte) de la ressource. Par exemple, le numero ISBN pour 
un livre, les URI et URL pour les ressources electroniques sont de bons candidats. Vous pouvez 
egalement utiliser ici vos propres identifiants uniques, tels les codes d'identification des modu- 
les (DMC ou Data Module Code) ou d'illustrations (ICN comme Illustration Code Number). 

Reference d'une ressource parente de la ressource presente. Cette reference peut etre, par 
exemple, I'identifiant unique de la ressource parente indiquee par son <dc:identifier>. 

Langue du contenu intellectuel de la ressource. II est recommande d'utiliser les codes de langue 
definis par la norme RFC 3066 combinee avec I'lSO 639. Cela permet de faire des combinaisons 
de type « fr-FR » pour le francais de France et « fr-AKK » pour le francais parle en Acadie. 

Reference d'une ressource en rapport avec la presente ressource. II est recommande d'utiliser ici 
I'identifiant unique de la ressource en question. 

Forme d'applicabilite de la ressource. Cette applicability peut etre geographique, temporelle ou 
juridique. II est recommande d'utiliser ici des noms, valeurs ou identifiants officiels. 

Detenteurs des droits de propriete sur le contenu de la ressource. L'information peut etre un 
texte explicite ou une reference a une ressource decrivant les droits de propriete. Ces droits con- 
cernent la propriete intellectuelle, le copyright, les conditions d'exploitation, de reutilisation, 
etc. 



En complement a ce jeu de base, des elements substituables aux premiers permettent 
de preciser les informations specifiees. Le tableau 11-2 les presente. La substitution 
des elements les uns par les autres est formellement definie dans les schemas XML 
correspondants (XML Schema dispose d'un mecanisme permettant de definir for- 
mellement les elements autorises en lieu et place d'autres). 
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Tableau 11-2 Elements substituables aux elements de base du Dublin Core 



Element Par Description 
substituable 


<dc:audience> 


Nouvel element L'audience type de la ressource. 




<dct:mediator> 


L'entite type qui gere I'acces a la ressource et pour qui elle est impor- 
tant^ (typiquement une bibliotheque). 


<dct:educationl_evel> 


Niveau de connaissances requis pour les utilisateurs de la ressource. 


<dc:coverage> 


<dct:spatial> 


Caracteristiques spatiales du contenu intellectuel de la ressource. 


<dct:temporal> 


Caracteristiques temporelles du contenu intellectuel de la ressource. 


<dc:date> 


<dct:available> 


Date de publication de la ressource. 


<dct:created> 


Date de creation de la ressource. 


<dct:dateAccepted> Date de validation ou d'acceptation de la ressource. 


<dct:dateCopyrighted> 


Date d'etablissement du copyright. 


<dct:dateSubmitted> 


Date de soumission de la ressource. 


<dct:medium> 


Support physique de la ressource. 


<dct:modified> 


Date de modification de la ressource. 


<dct:issued> 


Date de sortie formelle de la ressource. 




<dct:valid> Date de validite de la ressource. 


<dc:description> 


<dct:abstract> 


Resume du contenu de la ressource. 




<dct:tableOfContents> 


Table des matieres de la ressource. 


<dc:format> 


<dct:extent> 


Taille ou duree de la ressource. 


<dc:identifier> <dct:bibliographicCitation> Reference bibliographique. 


<dc:relation> 


<dct:conformsTo> Reference d'un standard auquel se conforme la ressource. 




<dct:hasFormat> 
<dct:isFormatOf> 


Relations « a le meme format que » et « est du meme format que ». 


<dct:hasPart> 
<dct:isPartOf> 


Relations « inclut » et « fait partie de ». 


<dct:hasVersion> 
<dct:isVersionOf> 


Relations « a comme version » et « est une version de ». La notion 
de version porte ici sur le contenu et non sur le format. 


<dct:references> 
<dct:isReferencedBy> 


Relations « reference » et « est reference par ». 


<dct:replaces> 
<dct:isReplacedBy> 


Relations « remplace » et « est remplace par ». 


<dct:requires> 
<dct:isRequiredBy> 


Relations « requiert » et « est requis par ». 
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Tableau 11-2 Elements substituables aux elements de base du Dublin Core 



Element Par Description 
substituable 


<dc:rights> 


<dct:license> 


Document legal specifiant les droits d'utilisation legaux de la res- 
source. 


<dct:rightsHolder> 


Detenteur des droits. 


<dct:accessRights> 


Droits d'acces a la ressource ou indication de son niveau de confiden- 
tialite. Par exemple, en cas de restrictions des droits d'acces pour des 
raisons de liberte individuelle, securite ou toute autre loi applicable. 


<dc:title> 


<dct:alternative> 


Titre secondaire de la ressource qui peut etre une version traduite du 
titre ou un titre abrege. 



Precision Espaces de noms dc et dct 

Les elements de base du Dublin Core et ceux qui leur sont substituables font partie de deux espaces de 
noms differents. Reperes dans le tableau 1 1 -2 par les prefixes dc et dct, leurs noms complets sont res- 
pectivement http : //pu r~\ . org/dc/el ements/1 . 1/ et http : //purl . org/dc/terms/. 



La specification Dublin Core precise egalement les normes de codification applica- 
bles (telles les normes ISO 3166, 639-1, 639-2, RFC 1766 et 3066, qui specifient les 
codes de langues et pays, ainsi que la maniere de les combiner pour former des cou- 
ples langue/pays). 

L'exemple suivant montre un cas concret d'utilisation des elements du Dublin Core, 
utilisant des elements des tableaux 11-1 et 11-2. 



<dc:title>Solenoid Valve, Pump No. 1 (No. 2) - Remove Procedures 

</dc:title> 

<dc : i denti f i er>lB-B-29-ll-01-06A-520A-A_003</dc : i denti f i er> 

<dct : i sVersi onOf>lB-B-29-ll-01-06A-520A-A_002</dct : i sVersi onOf> 

<dct : i ssued>2001-04-01</dct : i ssued> 

<dc : creator>C0419</dc : creator> 

<dc:subject>Soleno"id Valve, Pump No. 1 (No. 2)</dc: subject> 

<dc : type>Remove Procedures</dc : type> 

<dc : publ i sher>C0419</dc : publ i sher> 

<dc : cont ri butor>C0419</dc : cont ri butor> 

<dc : date>2001-04-01</dc : date> 

<dc : format>text/xml </dc : f ormat> 

<dc : 1 anguage>sx-GB</dc : 1 anguage> 

<dc : ri ghts>l</dc : ri ghts> 

<dct:conformsTo>-//Aecma//DTD Aecma 1000D Procedural 20010401//EN 

</dct : conformsTo 
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Enfin, nous donnons ci-apres un exemple concret d'utilisation de Dublin Core dans 
un module S1000D : 

<?xml version="1.0"?> 

<! --PUBLIC "-//S1000D//DTD S1000D Procedural 20030531//EN"--> 

<!DOCTYPE dmodule [ ]> 

<dmodul e xml ns : xsi ="http : //www . w3 . org/2001/XMLSchema-i nstance" 
xsi :noNamespaceSchemaLocation="procedSchema.xsd" 
xmlns: rdf=" http://www.w3.Org/1999/02/22-rdf-syntax-ns#" 
xml ns : dc="http : //www. pu rl . org/dc/el ements/1 . 1/" 
xml ns : xl i nk=" http : //www . w3 . o rg/1999/xl i nk"> 
<rdf : Description 

<dc:Title>Multifunction Head Down Display, LH - Remove Procedures 

</dc:Title> 

<dc : Creatorx/dc : Creator> 

<dc:Subject>Multi function Head Down Display, LH - Remove Procedures 

</dc:Subject> 

<dc : Publ i sher>I9005</dc : Publ i sher> 

<dc:Contributorx/dc:Contributor> 

<dc:Date>2003-05-31</dc:Date> 

<dc : Identi f ier>lB-A-31-15-01-OOA-520A-A 004</dc : Identi f ier> 

<dc : Ri ghts>01</dc : Rights> 
</rdf : Descr i pti on> 
<idstatus> 
<dmaddres> 
<dmc> 
<avee> 

<model i olB</model i c> 
<sdc>A</sdc> 
<chapnum>31</chapnum> 
<secti on>l</secti on> 
<subsect>5</subsect> 
<subject>01</subject> 
<di scode>00</di scode> 
<di scodev>A</di scodev> 
<i ncode>520</i ncode> 
<i ncodev>A</i ncodev> 
<i teml oc>A</i teml oc> 
</avee> 
</dmc> 
<dmtitle> 

<techname>Multi function Head Down Display, LH</techname> 
<infoname>Remove Procedures</infoname> 
</dmtitle> 
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<issno issno="004" inwork="00" type="changed"> 

</"issno> 

<issdate year="2003" month="05" day="31"> 

</issdate> 

</dmaddres> 

<status> 

<security class="01"> 

</secun'ty> 

<dmsize>4 Pages</dmsize> 

<rpc>I9005</rpc> 

<origx/orig> 

<appl i cx/appl i c> 

<techstd> 

<authbl kx/authbl k> 

<authexx/authex> 

<notesx/notes> 

</techstd> 

<qa> 

<unveri fx/unveri f > 

</qa> 

<sbc>XlBA311501000</sbc> 

<ski"ll skill="sk01"> 

</skil1> 

<remarks>None</remarks> 

</status> 

</"idstatus> 

Que remarque-t-on ? 

Pour parer aux insuffisances du Dublin Core, certaines donnees qui faisaient l'objet 
de plusieurs balises XML dans le modele originel sont concatenees quand le 
Dublin Core est utilise. C'est le cas du code du module, ecrit sous la forme 
<dc:Identifier>lB-A-31-15-01-OOA-520A-A_004</dc: Identifiers, alors que cela 
fait l'objet a l'origine des 12 balises contenues dans 1' element dmc et de l'attribut 
issno de l'element issno. De meme, le titre et la nature de l'information contenue 
dans le module, les elements dmtitle et infoname, sont concatenees et deviennent 
<dc:Title>Multifunction Head Down Display, LH - Remove Procedures</ 
dc:Title>. Enfin, la date, ecrite a l'origine sous la forme de trois attributs, devient 
une chaine de caracteres : <dc:Date>2003-05-31</dc:Date>. On comprend des lors 
mieux les vraies differences qu'entraine le choix de l'une ou l'autre approche : les 
deux sont porteuses d'une meme information, mais l'une permet indeniablement de 
mieux controler la qualite de l'information transmise. 
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Metadonnees definies par RDF 



RDF, ou Resource Description Framework, est un modele de donnees concu pour 
definir des descripteurs de ressources web. RDF est un meta-modele puisque qu'il 
sert a definir des modeles de descripteurs. Autant le Dublin Core definit un vocabu- 
laire concret et precis pour specifier des metadonnees, autant RDF necessite de 
definir un vocabulaire et la structure qui l'accompagne. Aussi, le Dublin Core est-il 
considere comme une application de RDF. 

RDF est le resultat d'un travail realise par le W3C pour inventer un langage afin 
d'apporter de la semantique aux pages web (plus connu sous le nom de Web seman- 
tique). Son but est d'aboutir a un langage comprehensible par les ordinateurs et les 
humains. RDF est un « modele pour modeliser » les metadonnees. En ce sens, RDF 
n'est pas un enfant de XML Schema mais plutot un confrere, et il s'accompagne 
d'une specification d'ecriture de modele qui lui est propre : RDF Schema. C'est ce 
qui va rendre son etude interessante car, tout en etudiant les concepts lies a la mise en 
ceuvre de metadonnees, nous allons voir un cas pratique ou ni les DTD, ni 
XML Schema n'est utilise pour modeliser des documents XML. 



Vocabulaire Web semantique 

L'expression Web semantique designe I'ensemble des techniques necessaires pour que la recherche 
d'information sur le Web soit rendue plus performante. Aujourd'hui, les mots des pages HTML sont 
indexes par les moteurs de recherche sans distinction de langue, terminologie, sens et criteres de classifi- 
cation. Aussi, quand on cherche « cheval », d'une part on ne trouve pas « chevaux » mais, de plus, le 
systeme retourne sans distinction toutes les pages de toutes les utilisations possibles du mot cheval (che- 
val, « etre a cheval sur », cheval d'arcon, fievre de cheval, cheval de Troie, cheval fiscal...). Pour lutter 
contre ce bruit, il faut que les contenus des pages Web soient, en tout ou partie, classes, mis dans des 
rubriques thematiques et que la langue des vocabulaires qui s'y trouve utilises soit elle-meme reconnue. 



Bien que sa premiere cible soit le Web semantique, et done HTML, RDF permet 
d'exprimer des ensembles de metadonnees en XML independamment du format 
intrinseque de la ressource decrite. II n'est meme pas necessaire quelle soit accessible 
informatiquement. 

Au-dela de la description des ressources, RDF etablit des relations entre leurs pro- 
prietes. Un modele RDF peut, sur ce plan, etre compare a un diagramme de classes. 

RDF respecte la liberte d'identification : chaque communaute culturelle, profession- 
nelle, linguistique a ses propres mots-cles pour cataloguer l'information. Les memes 
mots sont importants dans certains contextes et vides de sens dans d'autres : le 
numero ISBN d'un ouvrage concerne principalement les acteurs de la chaine de dif- 
fusion, et plus rarement le lecteur pour lequel il se trouve n'etre d'aucune utilite pour 
rechercher une information sur le Web ou dans les rayonnages d'un libraire. Le 
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numero de securite sociale d'un individu nest interessant que si Ton sait qu'il s'agit 
d'un numero de securite sociale, sinon c'est un nombre ordinaire. Un article de 
journal n'a de sens que si Ton connait sa date de parution... Les exemples ne man- 
quent pas montrant que les choses n'ont de sens que si on peut les placer par rapport 
a un referentiel de connaissances. 

RDF ne donne pas de listes des noms a utiliser pour decrire une ressource mais spe- 
cific les mecanismes pour les definir et les controler. De meme que la recommanda- 
tion XML Schema n'a jamais pretendu imposer un quelconque vocabulaire XML 
autre que le sien, RDF est un modele permettant de definir un vocabulaire approprie 
aux caracteristiques d'une classe de ressources. 



Vocabulaire Ressource au sens RDF 

Pour RDF, une ressource est aussi bien un nceud d'un schema RDF (il s'agit des elements de base de type 
classe, propriete, type et domaine expliques dans cette section), d'un fichier, d'un URI, d'une valeur 
exprimee a I'interieur du contenu d'un element ou d'une base de donnees. Toute ressource peut avoir des 
proprietes et etre liee a une autre explicitement ou implicitement. 



Concretement, un modele RDF traduit trois niveaux d'information : 

• Une description concrete de ressources ; cela revient a exprimer des affirmations, 
par exemple « la page Web http://www.cml.com/auto.html publiee par L. Nivert a ete 
e'crite par S. Avrane », ou l'adresse de la page Web et les deux noms propres sont 
des ressources. 

• Une description logique des ressources et de leurs proprietes ; cela revient a expri- 
mer des concepts tels que « une page Web », « un webmaster », « un auteur ». 

• Un modele pour etablir des relations logiques et concretes entre ces concepts et 
ressources. Par exemple : « Toute page Web est de la famille des pages HTML », 
« une page Web est editee par un webmaster », « une page Web a un auteur », « le 
webmaster est un humain », « 1' auteur est un humain », etc. Les relations expri- 
ment l'appartenance a une famille, une hierarchie, un ordre... 

RDF repose sur un modele a deux dimensions : dans l'une, on classe l'information 
hierarchiquement a la maniere du systeme des poupees russes de XML et dans 
l'autre, on navigue dans l'information independamment de toute hierarchie ; cette 
seconde dimension regroupe tous les liens. 

La terminologie RDF repose sur quatre mots : 

• La classe (class) qui represente un concept abstrait de classification des 
ressources ; par exemple, les classes des livres, humains, logiciels, auteurs, fruits... 

• La propriete (property) qui definit une caracteristique particuliere ; par exemple, 
les proprietes auteur, webmaster, editeur, longueur, hauteur, couleur... 
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• Le type (range) qui specifie la valeur autorisee d'une propriete ; par exemple, le 
nom d'un auteur doit etre de type chaine de caracteres, un numero de securite 
sociale doit etre un nombre entier positif commencant par 1 ou 2. 

• Le domaine (domai n) qui precise les classes auxquelles s' applique une propriete ; 
par exemple, la propriete auteur s'applique aux classes des livres, theses, articles 
de presse, chansons... 

Ce modele permet de creer les metadonnees independamment de la creation phy- 
sique des ressources alors que dans le monde issu de la programmation orientee 
objet, un objet doit d'abord etre cree par instanciation d'un modele avant qu'on 
puisse lui attribuer des proprietes par ailleurs limitees a la seule classe dont il est 
l'heritier. La figure 11-3 illustre ce modele. 



Figure 11-3 
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Des relations hierarchiques sont etablies a l'interieur des objets de base : les classes, 
les proprietes, les domaines et les types peuvent etre hierarchises tandis que des liens 
sont etablis entre n'importe lequel de ces objets et meme au-dela : les liens unissent 
les ressources RDF, quelles qu'elles soient. 
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En RDF, une metadonnee de base est un triplet compose d'une ressource, d'une pro- 
priete et de sa valeur. La figure 11-4 represente ce modele on ne peut plus generique. 



Figure 11-4 

La relation elementaire de RDF 



propriete 




Notez que, puisqu'en RDF les proprietes sont des objets a part entiere, le modele de 
base represente a la figure 11-4 indique qu'une relation est etablie, via la propriete 
etablie entre une ressource et une valeur ; la valeur et la propriete etant mises en rap- 
port avec une ressource et non pas l'inverse. Si RDF avait mis en oeuvre la forme 
habituelle de la modelisation de type objet, le schema aurait ete inverse : la ressource 
aurait une propriete intrinseque, ayant elle-meme une valeur en propre qui lui aurait 
ete attribute lors de l'instanciation de l'objet. Dans le monde classique des objets, on 
ne peut acceder a une propriete qu'en passant par un objet. La representation d'un tel 
modele aurait des lors ete semblable a celle de la figure 11-5. 



Figure 11-5 

La relation classique entre 
un objet et ses proprietes 




Commencons par un exemple de description d'une ressource : 

<rdf:RDF> 

<rdf : Descri pti on about="http : //www. poesi e . com/i 1 1 umi nati ons"> 
<ncn:Auteur>B. Estrade</ncn:Author> 

</rdf : Descri pti on> 
</rdf:RDF> 

On y exprime la relation entre la ressource http://www.poesie.com/illuminations, la pro- 
priete ncn : Auteu r et la valeur de cette propriete B . Estrade exprimee en toutes let- 
tres. Ecrite ainsi, on a la un objet classique (la ressource) qui a une propriete, qui a 
elle-meme une valeur. 
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Cependant, on aurait egalement pu ecrire cette description sous la forme : 

<rdf:RDF> 
<rdf : Descri pti on about="http : //www . poesi e . com/i 1 1 umi nati ons"> 
<ncn:Auteur rdf : ressource= 

"http : //www . poesi e . com/auteurs . html #estrade"/> 
</rdf : Desc ri pti on> 
</rdf:RDF> 

Dans cet exemple, la valeur de la propriete est mentionnee par une URL qui renvoie 
probablement sur une description plus complete de l'auteur B. Estrade. Remarquez 
simplement que l'element ncn : Auteur se comporte alors comme un element vide : la 
valeur d'un element est soit ecrite entre les balises de debut et de fin d'element, soit 
via un attribut href, les deux formes s'excluant mutuellement. 

L'exemple que nous voyons ici fait partie de l'application concrete de RDF. En 
resume, ce document XML est une instance d'un modele RDF Schema. On remar- 
quera qu'il mele deux vocabulaires : l'un issu de RDF reconnaissable a son prefixe rdf 
et l'autre issu d'un autre espace de noms et prefixe par ncn. 

De la meme maniere que XML respecte une syntaxe formelle, le vocabulaire des ele- 
ments de base de RDF est defini formellement par une notation BNF. Ni les DTD 
ni les schemas XML ne sont utilises : ils ne permettent pas d'exprimer certaines con- 
traintes dont RDF a besoin. 

Nous donnons ci-apres la definition simplifiee de RDF. 

[I] RDF ::= [ ' <rdf: RDF>'] description- ['</rc/f:RDF>'] 

[2] description ::= '<rdf: Descri pti on' idAboutAttr? '>' property* ' 

</rdf: Descri pti on> ' 
[3] idAboutAttr ::= idAttr | aboutAttr 
[4] aboutAttr : := 'about='" URI-reference "" 
[5] idAttr : := 'ID='" IDsymbol "" 
[6] property ::= '<' propName '>' value '</' propName '>' | '<' 

propName ressource '/>' 
[7] propName : := Qname 
[8] value : := description | string 
[9] ressource ::= ' ressource=" ' URI-reference '"' 
[10] Qname ::= [ NSprefix ':' ] name 

[II] URI-reference ::= string, interpreted per [URI] 
[12] IDsymbol ::= (any legal XML name symbol) 

[13] name ::= (any legal XML name symbol) 

[14] NSprefix ::= (any legal XML namespace prefix) 

[15] string ::= (any XML text, with "<" , ">", and "&" escaped) 
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On y retrouve facilement les definitions des mots-cles utilises dans notre exemple : 
les balises <rdf:RDF>, <rdf : Description (regies [1] et [2]), les attributs about et 
ressource (regies [4] et [9]) et les regies qui autorisent i'utilisation de noms d'ele- 
ments provenant d'autres schemas (regies [6], [7], [10] et [13]) tel ncn:Auteur qui 
est un nom qualifie autorise par la regie [6]. 

En XML Schema, la regie [6] aurait pu etre declaree ainsi : 

<any namespace="##other" processContents="strict" minOccurs="0" 
maxOccurs="unbounded"/> 

Cela ne serait pas du tout revenu au meme : 

• L'element autorise par RDF a un type de contenu bien impose : il s'agit soit d'une 
description RDF, soit d'une chaine de caracteres. 

• La regie 6 presente un choix entre un element ayant un contenu et un element vide. 
Dans le cas de l'element vide, la regie [6] impose l'usage de l'attribut href. On 
aurait egalement pu exprimer un tel choix en XML Schema. Cela eut ete absurde 
d'exprimer un choix en « n'importe quel element » et un element en particulier ! 

On constate ici sur un cas simple que XML Schema ne permettrait pas d'exprimer 
les contraintes dont les documents RDF ont besoin et que le recours a la notation 
BNF est ici justifie. 

Comme nous venons de le voir, la description d'une ressource est simple. La veritable 
puissance de RDF se situe au-dessus, dans sa capacite a modeliser des hierarchies de 
concepts et les liens entre les ressources comme cela est illustre a la figure 11-3, 
figure dans laquelle ce que nous venons de presenter est l'etage inferieur (repere ©). 

Parmi le vocabulaire autorise pour decrire les proprietes des ressources, nous avons vu 
que RDF autorisait l'usage de n'importe quel vocabulaire de n'importe quel espace de 
noms. RDF beneficie de cette possibilite et en profite pour definir un ensemble 
d'elements d'usage commun. 

Elements complementaires de RDF 

Dans cette section, nous presentons quelques elements RDF utilises dans les des- 
criptions de ressources. Ceux prefixes par rdf appartiennent a l'espace de noms des 
elements de base et ceux prefixes par rdf s relevent du vocabulaire complementaire. 



Detail technique Espaces de noms de RDF 

RDF est defini a travers deux espaces de noms : I'un forme le noyau de RDF et I'autre est compose d'ele- 
ments et attributs complementaires. Les espaces de noms correspondants sont respectivement 
http://www.w3.Org/1999/02/22-rdf-syntax-ns# (le prefixe associe le plus souvent est rdf) et 
http://www.w3.Org/2000/01/rdf-schema# (le prefixe le plus souvent associe est rdfs). 
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Pour illustrer le propos, nous nous appuyons sur un exemple concret : 

<rdf:RDF xml :lang="en" 

xmlns: rdf=" http://www.w3.Org/1999/02/22-rdf-syntax-ns#" 

xml ns : rdf s="http : //www. w3 . org/2000/01/ rdf -schema#"> 
<rdf: Description ID="Vehicles"> 

<rdf :type ressource="http://www.w3 .org/2000/01/rdf-schema#Class"/> 

<rdfs:subClassOf 

ressou rce="http: //www. w3.org/2000/01/ rdf -schema#Ressource"/> 

<rdf: Category ressource="#vehiclesTypes"> 
</rdf :Description> 
<rdf: Description ID="Constructeur"> 

<rdf :type ressource="http://www.w3 .org/2000/01/rdf-schema#Class"/> 

<rdfs:subClass0f res sou rce=" http://www.w3.org/2000/01/rdf- 
schema#Ressource"/> 
</rdf :Description> 
<rdf: Description ID="monoSpace"> 

<rdf :type ressource="http://www.w3 .org/2000/01/rdf-schema#Class"/> 

<rdfs:subClass0f ressource="#Vehicles"/> 

<rdfs:subClass0f ressource="#Constructeur"/> 
</rdf :Description> 
<rdf :Description ID="4x4"> 

<rdf :type ressource="http://www.w3 .org/2000/01/rdf-schema#Class"/> 

<rdfs:subClass0f ressource="#Vehicles"/> 

<rdfs:subClass0f ressource="#Constructeur"/> 
</rdf :Description> 
<rdf:Bag ID="vehiclesTypes"> 

<rdf:li ressource="#monoSpace "> 

<rdf:li ressource="#4x4"> 
</rdf :Bag> 

<rdf : Description ID="Proprietai re"> 
<rdf :type 

ressou rce="http: //www. w3.org/1999/02/22 -rdf- syntax- ns#P rope rty"/> 
<rdfs: domain rdf: ressou rce="#Vehicles"/> 
<rdf : Category ressource="#PropritairesTypes"> 
</rdf :Description> 

<rdf: Alternative ID="ProprietairesTypes"> 
<rdf: Description ID="personnePhysique"> 
<rdf :type 

res sou rce=" http://www.w3 .org/1999/02/22- rdf - syntax- ns#P rope rty"/> 
<rdfs : subPropertyOf rdf: ressource="#Proprietaire"/> 
</rdf : Descri pti on> 
< rdf : Description ID="personneMorale"> 
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<rdf :type 

res sou rce=" http://www.w3.Org/1999/02/22-rdf-syntax-ns#P rope rty"/> 
<rdfs:subPropertyOf rdf : ressource="#Proprietaire"/> 
<rdfs: range 

rdf: ressource="http: //www. w3.org/2000/01/ rdf -schema#LiteraV'/> 
</rdf : Descri pti on> 
</rdf : Alter native> 
</rdf:RDF> 

Ce document RDF est un schema au sens RDF, a savoir qu'il s'agit d'un modele de 
metadonnees. II fait intervenir, en plus de l'element rdf : Descri pti on et de l'attribut 
rdf : ressource que nous avons deja vus, les elements et attributs rdf:type, ID, 
rdfs: domain, rdfs: range, rdf : Property, rdfs:subClassOf et rdfs :subPropertyOf. 

Ce schema RDF decrit des classes, des proprietes et des relations entre des res- 
sources. Contrairement au premier exemple ou Ton appliquait directement des 
valeurs de proprietes a des ressources concretes via l'element rdf : Description, il 
nous sert cette fois a creer de nouvelles classes de ressources. En particulier, on notera 
que l'element rdf : Descri pti on sert ici a definir des ressources qui sont des noeuds 
intrinseques au schema. Finalement, on peut dire que ce schema est un systeme de 
nceuds dont certains sont des classes et les autres des proprietes : tous peuvent cepen- 
dant etre utilises comme ressources. 

Notre exemple cree deux classes generiques, Vehicles et Const ructeur. La classe 
Vehicles est composee de deux sous-classes qui sont les classes monospace et 4x4. 
L'element rdf : Bag permet de definir un groupe de classes ; ici, il est utilise pour 
definir les sous-classes constitutives du type VehiclesTypes. Les classes monospace 
et 4x4 sont toutes les deux des sous-classes des deux classes principales Vehicles et 
Constructeurs. La propriete Proprietaire est rattachee a la classe Vehicles et les 
proprietaires peuvent etre des personnes morales ou physiques. 



Remarque Terminologie 

Nous ramenons la terminologie generale de RDF a un vocabulaire proche de celui utilise globalement 
dans cet ouvrage afin de rendre possible les comparaisons entre les differents modeles exposes, quitte a 
etre reducteurs par rapport aux concepts reels decrits par la recommandation RDF. 



La suite de cette section est consacree a la description des elements RDF utilises 
dans cet exemple. 
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rdf:type 

Cet element indique le type de la ressource, et notamment s'il s'agit d'une classe ou 
d'une propriete. Les noeuds qui composent un document RDF sont de deux types : 
les ressources et les proprietes. Pour declarer une ressource comme etant de type 
classe, il faut ecrire : 

<rdf :type ressource="http://www.w3 . org/2000/01/rdf-schema#Class"/> 

Et pour la declarer comme propriete : 

<rdf :type 

ressou rce="http: //www. w3.org/1999/02/22-rdf-syn tax- ns#P rope rty"/> 

Quand une ressource est declaree comme classe, elle herite de toutes les proprietes 
definies pour les membres de cette classe. Comme le montre notre exemple, une res- 
source peut etre une instance de plus d'une classe (c'est le cas de monospace et 4x4). 

rdfs:subClassOf 

Comme son nom l'indique, cet element etablit une relation de hierarchie entre deux 
classes. Dans notre exemple, la relation peut etre multivaluee : une classe peut avoir 
plusieurs generalisations. Ce point est fondamental afin que 1'information puisse 
naviguer dans plusieurs directions. 



VOCABULAIRE Hierarchie de classe 

Une relation de type hierarchique entre classes est simplement une relation de type parent-enfant. Une 
classe derivee d'une autre peut etre consideree comme etant son enfant. Toutefois, une expression 
encore plus juste devrait etre « relation de type specialisation-generalisation » : elle indique qu'une 
classe est simplement plus generale qu'une autre, cette derniere etant qualifiee de specialised. 



rdfs:subPropertyOf 

L' element subPropertyOf est utilise quand une propriete est restrictive par rapport a 
une autre ou plusieurs. Les proprietes peuvent, par ce biais, etre hierarchisees. Dans 
l'exemple, on met en place un modele permettant de decrire des liens familiaux. On 
ecrit le fait que les proprietes Pere et Mere sont des specialisations de la propriete 
Parents, elle-meme etant une specialisation de la propriete Ancetres. 

<rdf:RDF xml :lang="en" 

xml ns : rdf="http : //www . w3 . org/1999/02/2 2- rdf -syntax-ns#" 

xmlns: rdfs="http://www.w3 .org/2000/01/ rdf- schema#"> 
<rdf: Description ID="Ancetres"> 
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<rdf : type 

ressou rce="http: //www. w3.org/1999/02/22-rdf-syn tax- ns#P rope rty"/> 
</rdf :Description> 
<rdf: Description ID="Parents"> 
<rdf : type 

ressou rce="http: //www. w3.org/1999/02/22-rdf-syn tax- ns#P rope rty"/> 
<rdfs : subPropertyOf rdf : ressource="#Ancetres"/> 
</rdf :Description> 
<rdf :Description ID="Pere"> 
<rdf : type 

ressou rce="http: //www. w3.org/1999/02/22- rdf -syn tax- ns#P rope rty"/> 
<rdf s : subPropertyOf rdf: ressource="#Parents"/> 
</rdf :Description> 
<rdf :Description ID="Mere"> 
<rdf : type 

ressou rce="http: //www. w3.org/1999/02/22 -rdf -syn tax- ns#P rope rty"/> 
<rdfs : subPropertyOf rdf: ressource="#Parents"/> 
</rdf : Descri pti on> 
</rdf:RDF> 

Ces liens expriment une hierarchie de proprietes. En transposant les noms des pro- 
prietes en noms d'elements XML, la logique exprimee par ces liens prendrait la 
forme suivante : 

<Ancetres ressource="..."> 

<Parents ressource="..."> 

<Pere ressource="..."/> 

<Mere ressource="..."/> 

</Parents> 

</Ancetres> 

On pourrait imaginer d'en ecrire le schema XML correspondant mais on rencontre- 
rait un probleme : a la difference d'un schema XML, un schema RDF permet d'ecrire 
un document RDF reduit a 1' element pere sans pour autant perdre la logique Ance- 
tres/Parents/Pere. En d'autres termes, un schema RDF definit la semantique des rela- 
tions entre les ressources que les documents RDF n'ont ensuite plus besoin d'exposer. 



Remarque Recursivite 

Pour les deux elements precedents, la recursivite est interdite, qu'elle soit directe ou indirecte (une sous- 
classe ne peut pas se trouver etre une sous-classe d'elle-meme et il en va de meme avec les sous-proprietes). 
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rdfs:seeAlso et rdfs:isDefinedBy 

L'element seeAl so specifie un lien de type index. L'element i sDef i nedBy represents une 
sous-propriete de seeAl so. Dans les deux cas, la valeur de ces elements est une ressource. 

rdfs:domain et rdfs:range 

L'element rdfs: domain specifie la classe a laquelle s'applique une propriete (voir 
figure 11-4). Par exemple, on utilise rdfs: domain pour indiquer que la propriete 
auteur s'applique aux objets (ressources) de la classe Livre. Une propriete peut avoir 
comme domaine zero, une ou plusieurs classe(s). S'il n'y a pas de domaine, la pro- 
priete peut etre utilisee dans n'importe quelle ressource, et quand un domaine est 
defini, la propriete ne peut alors etre utilisee que pour les objets (ressources) des 
classes correspondantes. 

L'element rdfs: range permet de specifier la valeur d'une propriete en indiquant la 
classe a laquelle cette valeur doit appartenir. Par rapport a ce qui ce fait habituelle- 
ment en XML pour definir un type de contenu, RDF utilise ici un mecanisme ori- 
ginal. Par exemple, rdfs : range permet d'imposer qu'un nom d'auteur soit une res- 
source appartenant a la classe des personnes. La valeur de rdfs : range ne doit 
correspondre qua une et une seule classe (si on souhaite quelle s'applique a plusieurs 
classes, il suffit de passer par une super-classe). 

Le fragment ci-apres est un exemple d'utilisation des elements rdfs: range et 
rdfs:domain. On y specifie que la propriete millesime de la classe des entiers de 
XML Schema (xs:interger) s'appliquera aux objets de la classe vehicles. Quant a 
elle, la classe vehicles est une sous-classe de la classe mere de toutes les classes : 
rdf-schema#Ressource. 

<rdf:RDF xml :lang="en" 

xml ns : rdf="http : //www. w3 . org/1999/02/2 2- rdf -syntax-ns#" 
xmlns: rdfs="http://www.w3 .org/2000/01/ rdf- schema* " 
xml ns:xs=" http://www.w3.org/2001/XMLSchema"> 
<rdfs:Class rdf :ID="vehicles"> 
<rdfs:subClassOf 

rdf: res sou rce=" http://www.w3 .org/2000/01/ rdf- schema#Res sou rce"/> 
</rdfs:Class> 

<rdf: Property ID="millesime"> 
<rdfs : range rdf: ressource="xs : i nteger"/> 
<rdfs: domain rdf: ressource="#vehicles"/> 
</rdf : Property> 
</rdf:RDF> 
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Metadonnees relatives au contenu du document 

Depuis le debut de ce chapitre, nous avons etudie les metadonnees qui s'appliquent a 
la totalite d'un document XML, voire d'une collection de documents XML ou res- 
sources. En quelque sorte, ces metadonnees figuraient a l'exterieur des documents 
eux-memes. 

Nous allons desormais plonger au cceur des documents XML et etudier, a partir de 
cette section, les metadonnees qui peuvent y etre utilisees. 

II n'existe, dans un document, que deux moyens pour exprimer des metadonnees : 

• les attributs 

• les elements. 

Metadonnees transmises par un attribut 

Lattribut qui porte la metadonnee peut etre de deux natures differentes : 

• II est public et appartient a un espace de nom specialise dans la transmission de 
metadonnees. 

• II est prive et appartient a l'application. 

Nous allons dans cette section prendre pour exemple les cas mis en ceuvre par 
SOAP ; il s'agit d'un modele concu pour transmettre des donnees, et en particulier 
les metadonnees qui les accompagnent. 

Une premiere possibility est de referencer le schema XML qui contient la definition 
du type de la donnee transportee. Cette methode n'est applicable que dans le cas de 
documents XML bien formes, qui ne se sont pas vu attribuer de schema XML global. 

<t : i denti f i cati on xml ns : t="http : //www . car Buy . org/schema . xsd">05-1997 
</t : i denti f i cati on> 

Le fragment precedent indique que la valeur 05-1997 transportee dans l'element 
identification est du type defini pour l'element identification dans le schema 
dontl'URI est http://www.carBuy.org/schema.xsd. 

Une deuxieme technique consiste a utiliser i'attribut fiottant xsi :type et de faire, 
comme dans 1' exemple suivant, un typage dynamique des elements : 

<i denti f i cati on xsi : type="xsd : i nt" 

xmlns :xsi=" http://www.w3 . org/2001/XMLSchema- in stance" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema">51997 

</i denti f i cati on> 
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Dans cet exemple, on assigne le type entier de XML Schema a l'element 
identification. 

Metadonnees transmises par une structure d'elements 

Enfin, une troisieme technique consiste a utiliser une structure plus complexe. 
SOAP, par exemple, autorise a declarer dynamiquement le modele de contenu d'un 
element au travers de deux mecanismes originaux : les accessoires polymorphes et les 
tableaux d'elements. 



Information soap 

SOAP est un protocole d'echange de donnees adapte a Internet et aux besoins des services Web. 



Les tableaux d'elements sont definis au moyen du type soap-enc: Array : 
<element name="myFavoriteNumbers" type="soap-enc:Array"/> <" © 

Dans cet exemple, l'element myFavoriteNumbers est declare comme etant de type 
tableau (repere ©). 

Letape suivante consiste a indiquer le type des elements constitutifs du tableau. Cela 
se fait, lors de 1'utilisation du tableau, en utilisant l'attribut soap-enc :arrayType 
(repere O) : 

<myFavoriteNumbers soap-enc :arrayType="xsd:int [2] "> <- O 

<number>3</number> <- © 

<number>4</number> <- © 
</myFavoriteNumbers> 

Le type choisi est ici xsd : i nt, ce qui signifie que c'est le type entier de XML Schema 
qui est retenu (reperes © et ©). 

Une autre possibilite autorisee est d'utiliser directement l'element Array, comme ceci : 

<enc: Array xmlns :enc=" http://www.w3 .org/2001/12/soap-encoding" 

xm"lns:xs="http: //www. w3.org/2001/XMLSchema" 

enc:ArrayType="xs:int[2] " > 
<enc : i nt>3</enc : i nt> 
<enc : i nt>4</enc : i nt> 
</enc:Array> 
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Remarquez que, dans ce fragment, on a declare l'espace de noms de l'element Array. 
La dimension du tableau a ete specifiee au moyen de l'attribut ArrayType, et elle est 
ici de 2. Toutefois, il serait trompeur de croire que cet attribut impose egalement le 
type des donnees transmises : leur veritable type est specifie par l'utilisation directe 
du nom du type comme nom d'element, a savoir enc:int. Dans SOAP, chaque type 
predefini de XML Schema se voit associe a un element qui porte son nom. Cela est 
l'un des mecanismes particuliers de SOAP. II comporte une contrainte toutefois : le 
type utilise au niveau des elements du tableau doit etre une derivation valide de celui 
declare au niveau de l'attribut ArrayType. 

Aussi, en utilisant le pere de tous les types dans l'attribut enc : Ar rayType, c'est-a-dire le 
type ur (repere ©), on peut creer des tableaux contenant des donnees de n'importe quel 
type (reperes ©, O, © et ©). Lexemple suivant fournit deux cas d'application. Dans 
l'un, un element intermediate thi ng est utilise pour porter les donnees, et dans l'autre 
elles sont portees par des elements SOAP autodescripteurs de leur type de contenu. 

<soap-enc:Array soap-enc:arrayType="soap-enc:ur-type[4]"> <- © 
<thing xsi :type="xsd:int">12345</thing> <- © 
<thing xsi :type="xsd: decimal ">6, 789</thing> <- © 
<thing xsi :type="xsd:string"> <- © 

Of Mans First Disobedience, and the Fruit 

Of that Forbidden Tree, whose mortal tast 

Brought Death into the World, and all our woe, 

</thing> 

<thing xsi :type="xsd:uri Reference's <- © 
http : //www . dartmouth . edu/~mi 1 ton/readi ng_room/ 

</thing> 
</soap-enc:Array> 
<soap-enc:Array soap-enc:arrayType="soap-enc:ur-type[4]"> <- © 

<soap-enc:int>12 345</soap-enc:int> <- 

<soap-enc:decimal>6, 789</soap-enc:decimal> <- © 

<xsd:string> <- © 

Of Mans First Disobedience, and the Fruit 

Of that Forbidden Tree, whose mortal tast 

Brought Death into the World, and all our woe, 

</xsd:string> 

<soap-enc:uriReference> <- © 
http : //www . dartmouth . edu/~mi 1 ton/readi ng_room/ 

</soap-enc:uri Reference > 
</soap-enc:Array> 

Nous venons d'etudier un premier type de tableaux, celui ou les donnees transmises 
sont de type simple. Nous allons desormais voir comment transmettre des tableaux 
de donnees complexes. 
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A la difference des tableaux de type Array, ceux de type Struct permettent de trans- 
porter des structures complexes : chaque element du tableau ne contient plus directe- 
ment la valeur a transmettre, mais une serie de balises emboitees les unes dans les 
autres. La syntaxe definie pour specifier le nom de l'element compose qui servira 
d'item au tableau est tres proche de ce que nous venons de voir. Comme le montre 
l'exemple suivant, le nom qualifie de l'element complexe utilise dans le tableau est 
declare en lieu et place du nom du type simple dans la valeur de l'attribut 
soap-enc:arrayType. Le repere © indique la ligne utilisee pour declarer l'espace de 
noms de l'element Order, et le repere © celle ou est declare le tableau compose des 
elements de type Order. Les reperes © et O indiquent les endroits ou sont concrete- 
ment utilises les elements du tableau ainsi definis. 

<soap-enc : Array xml ns : enc="http : //www . w3 . org/2001/12/soap-encodi ng" 
xmlns :xyz=http: //example. org/2001/06/Orders <- © 
soap-enc:arrayType="xyz:Order[2]"> <- © 
<Order> <- 
<Product>Pomme</Product> 
<Pri ce>l, 56</Pri ce> 
</Order> 
<Order> <- O 
<Product>Peche</Product> 
<Pri ce>l, 48</Pri ce> 
</Order> 
</soap-enc:Array> 

La technique du referencement de contenus externes par le mecanisme des id/href 
detaille plus avant permet de construire des tableaux de tableaux. L'exemple suivant est un 
tableau compose de deux tableaux (reperes ©, et O). Les sous-tableaux sont eux-memes 
constitues respectivement de trois (repere ©) et deux (repere ©) chaines de caracteres. 

<soap-enc:Array soap-enc:arrayType="xsd:string[] [2]"> <- © 
<item href="#array-l"/> <r © 
<item href="#array-2"/> <- O 

</soap-enc:Array> 

<soap-enc:Array id="array-l" soap-enc:arrayType="xsd:string[3]"> <- © 

<i tem> rlcl</i tem> 

<i tem>rlc2</i tem> 

<i tem>rlc3</i tem> 
</soap-enc:Array> 
<soap-enc:Array id="array-2" soap-enc:arrayType="xsd: string [2] "> <- © 

<i tem> r2cl</i tem> 

<i tem> r2c2</i tem> 
</soap-enc:Array> 
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Les tableaux peuvent etre multidimensionneh. Pour cela, la valeur entre crochets 
devient un couple de valeurs : la premiere donne le nombre de sous-tableaux et la 
seconde le nombre d'items de chacun d'eux. Dans l'exemple suivant, on specifie que 
les deux sous-tableaux sont constitues de trois items : 

<soap-enc : Array soap-enc : ar rayType="xsd : stri ng[2 , 3] "> 
<!-- premiere serie --> 

<i tem>rlcl</i tem> 

<i tem>rlc2</i tem> 

<i tem>rlc3</i tem> 
<!-- deuxieme serie --> 

<i tem>r2cl</i tem> 

<i tem>r2c2</i tem> 

<i tem>r2c3</i tem> 
</soap-enc:Array> 

Meme si SOAP contient d'autres mecanismes qui permettent, entre autres, de ne 
transmettre que quelques valeurs d'un tableau, nous en avons vu ici l'essentiel, a 
savoir un mecanisme sophistique pour declarer dynamiquement des types dans le 
corps meme du document XML. 



En resume 



Dans ce chapitre, nous avons passe en revue plusieurs techniques de transmission des 
metadonnees avec les documents XML. 

On peut y proceder au travers des schemas XML quand ils existent et sont accessi- 
bles ou, de maniere peu exploitable, en produisant le PSVI du document XML avant 
de le transmettre. 

Les metadonnees peuvent concerner une donnee elementaire, et servent alors a en 
exprimer le type et potentiellement leur semantique, ou concerner l'entite document 
et representer alors ses donnees de gestion. 

Des jeux tout faits de metadonnees sont disponibles : c'est le cas du Dublin Core, un 
ensemble predefini d'elements valables pour tous types de documents textuels et de la 
S1000D, mais, dans ce dernier cas, les metadonnees sont specifiques a un metier 
bien particulier. Toutefois, des entreprises se sont deja inspirees de ces modeles pour 
developper leurs propres jeux de metadonnees. 

Enfin, nous avons vu des modeles qui servent a decrire des modeles plutot sophisti- 
ques de metadonnees, cela independamment des documents XML eux-memes. Le 
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modele RDF permet via les metadonnees de decrire des bases de connaissances et 
d'etablir entre les ressources de ces bases des relations typees. 

Quant a SOAP, nous avons utilise ce standard pour montrer le mecanisme original qui 
est mis en oeuvre afin de transmettre dynamiquement des informations de typage, tant 
sur des structures simples que complexes, en l'occurrence des tableaux de donnees. 

La gestion des metadonnees nous amene naturellement vers la gestion des liens, qui 
fait l'objet du chapitre suivant. En effet, comme nous l'avons vu avec RDF, gerer des 
metadonnees sans gerer les relations qui les rapprochent serait comme donner un 
coup d'epee dans l'eau. Ainsi, nous allons voir au chapitre suivant les mecanismes sus- 
ceptibles d'etre mis en ceuvre pour gerer des liens, du plus simple au plus complique. 



12 

Modeles pour 
la gestion des liens 



Le modele XML est particulierement propice a la pose de liens. Comme nous allons 
le voir dans ce chapitre, ce sujet est particulierement critique et exacerbe : 

• Critique, car a priori le moindre des documents XML contient des liens. II peut 
evidemment se produire des cas ou des documents XML ne contiennent pas de 
liens, mais c'est tres rare. 

• Exacerbe, car il peut arriver que des documents XML n'aient physiquement 
aucun contenu ; ce dernier est alors entierement stocke a l'exterieur du document 
d'ou il est reference par des liens. Dans certains cas egalement, des documents 
XML peuvent avoir pour seule vocation de definir des faisceaux de liens ; nous en 
avons eu un apercu au chapitre precedent avec RDF. On y a meme considere la 
possibilite de typer un lien et d'obtenir ainsi une relation. 

On dit de ces cas extremes que ce sont des documents massivement hyperlies. II ne 
s'agit pas de cas exceptionnels : un catalogue de composants d'un systeme complexe 
peut contenir jusqu'a 100 000 liens, une encyclopedic entre 400 000 et 500 000, etc. 

Le probleme des liens est general au monde des documents et s'etend done a celui de 
la donnee. 

Nous allons etudier dans ce chapitre les differents cas de liens et les solutions a 
apporter a cette question. 
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Les differents types de liens 



VOCABULAIRE Lien UML vs lien XML 

Dans UML, le terme de lien designe une relation faite entre objets au moyen de leur reference, laquelle 
permet de definir le role desdits objets. Dans XML, le lien designe le mecanisme qui permet de passer 
d'un element a un autre sans transiter par la hierarchie parent-enfant propre a XML. Ainsi, le lien permet 
de passer d'un element A a un element B de facon totalement independante de la structure des docu- 
ments dans lesquels se trouvent les elements A et B. On appelle cette forme de deplacement a I'interieur 
d'un document XML « navigation transversale non-lineaire » en opposition a « la navigation lineaire » 
qui, dans un document XML, represente des deplacements qui suivent I'arborescence XML du document. 



Depuis le lien simple reliant deux elements XML jusqu'au lien sophistique exprime 
sous la forme d'une expression calculee, XML offre une palette de possibilites que nous 
allons decrire dans cette section. Nous avons deja eu l'occasion, dans les chapitres pre- 
cedents, d'evoquer la question en presentant des liens de type RDF au chapitre 11. 

En XML, les liens, comme les donnees, peuvent etre types et avoir leur propre 
modele : en d'autres termes, les liens sont exprimes directement ou au travers de 
structures XML. Listons d'ores et deja les categories suivantes : 

• Les liens de type document : renvois de tables des matieres, figures, tableaux, 
index, bibliographies... lis sont calcules. 

• Les liens informatifs de navigation transversale : references croisees entre un texte 
et une illustration, un tableau, etc. lis sont poses par les auteurs ou calcules a par- 
tir de regies metier. 

• Les liens de navigation hierarchique par la structure : liens entre chapitres, sec- 
tions, etc. lis sont definis implicitement par le schema XML et sont calcules 
automatiquement. On peut naviguer de deux manieres : l'axe parent-enfant (on 
saute de chapitre en section...) et l'axe des noms d'elements (on saute de paragra- 
phe en paragraphe, de titre en titre, etc.) 

• Les liens volatils de navigation par le contenu : suite a une recherche de mots, on 
utilise par exemple la fonction « mot suivant ». 

• Les liens de referencement, qui sont des pointeurs vers des objets stockes a l'exte- 
rieur du document (programmes, animations, sequences visuelles, etc.). 

• Enfin, les liens d'inclusion de contenu : il s'agit d'appels pour aller chercher du 
contenu a l'exterieur du document. 

Quel que soit le cas de figure, les liens definis sont soit logiques, soit physiques, a 
savoir : 

• Un lien logique associe indirectement des ressources physiques ; generalement via 
des descriptions abstraites de ces ressources physiques. 
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• Un lien physique associe physiquement deux (ou plus) ressources physiques : une 
URL en est un exemple typique. 

Toutes ces distinctions vont etre presentees dans les prochaines sections. 



Liens logiques et physiques 

Liens physiques 

Un lien physique associe deux ressources en indiquant dans l'une le chemin d'acces 
physique qui conduit a l'autre. Comme a la figure 12-1, les URL de HTML sont les 
meilleurs representants de cette categoric 

Ces liens posent le probleme du deplacement d'une ressource : il faut dans ce cas 
changer « en dur » dans toutes les pages HTML l'ensemble des URL pointant vers la 
ressource deplacee. 

Ce probleme n'est meme pas minimise par l'utilisation d'URL relatives. En effet, 
l'interet des URL relatives est seulement de pouvoir deplacer en bloc un ensemble de 
pages HTML. Cependant, quand une seule est deplacee, le probleme mentionne 
precedemment persiste. 



VOCABULAIRE Ressource 

On appelle ressource tout objet d'un systeme adressable au moyen d'une URL. 



VOCABULAIRE URL 

URL est I'acronyme de Uniform Resource Locator, en francais pointeur uniforme de ressources. II s'agit 
d'une forme de syntaxe donnant une adresse universelle a un objet informatique ; c'est le 
http://www.xxx.yy/abc... bien connu des internautes. Les URL ne se limitent toutefois pas au 
seul protocole HTTP et a Internet, et toutes les possibility d'adressage sont definies par la RFC 1738 de 
decembre 1994 (les RFC sont des normes emises par I'lETF - Internet Engineering Task Force). 



Technique URL absolue et URL relative 

Une URL absolue exprime I'adresse d'une ressource a partir de la racine de la machine sur laquelle elle se 
trouve. Par exemple, I'URL absolue du texte de I'lETF definissant les URL est 
http : //www . i etf . org/rf c/rf cl738 . txt. 

A contrario, une URL relative est donnee par rapport a une autre. Cela est possible a condition que les 
deux ressources se trouvent sur la meme machine. Par exemple, des URL relatives du meme texte norma- 
tif pourraient etre . . /rf cl738 . txt ou . /rf cl738 . txt, ou encore . . / . . /rf cl738 . txt. 
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Figure 12-1 

Schema du principe 
de fonctionnement 
d'un lien physique 



Liens logiques 



Ressource source 



Lien physique 



Ressource cible a I'URL 
http://www.xmldev.com/tg.html 



ii <a href="http:// www.xmldev.com /tg.html#x514"> " 



<a name="x514>. 



ii . _ _" 



Un lien est logique quand la cible est specifiee au moyen d'identifiants la represen- 
tant logiquement, par exemple en utilisant des URI - Uniform Resource Identifier 
(en francais, identifiant uniforme de ressource). Ces derniers doivent, a un moment 
donne, etre transformes en identifiants physiques (en URL par exemple) pour que la 
ressource cible soit connue et atteinte. La figure 12-2 illustre ce cas de figure. 



VOCABULAIRE URI 

Un URI, ou identifiant uniforme de ressource, est un nom donne a une ressource. Un URI repond aux 
memes regies d'ecriture qu'une URL mais avec cette difference qu'il n'est pas cense etre le chemin 
d'acces reel de la ressource. Pour trouver la ressource physique, il faut etablir une correspondance entre 
I'URI de la ressource et son URL. 



Figure 12-2 

Schema du principe 
de fonctionnement 
d'un lien logique 




Ressource source 



Ressource cible a I'URL 
http:Avww.xmldev.com/tg.html 



La caracteristique des liens logiques est qu'ils peuvent etre definis a l'exterieur du 
document XML dans lequel on ne place plus que des indicateurs, qu'il s'agisse 
d'identifiants ou d'autres techniques de ciblage telles que des expressions Xpath. 

Dans la figure 12-2, les identifiants logiques locaux sont les chaines de caracteres 
3XB12 et x514. Lidentifiant 3XB12 est logique : il ne correspond directement a aucune 
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ressource physique. Pour la connaitre, il faut qu'un programme interprete cet identi- 
fiant logique en mettant en oeuvre l'algorithme suivant : 

• tout d'abord, savoir qu'il doit consulter la base 1 ; 

• puis trouver la base cible associee a l'identifiant logique ; 

• atteindre la base 2 au moyen d'une fonction / ; 

• trouver dans la base 2 l'identifiant logique local cible ; 

• trouver dans la base 2 l'URI (adresse logique) de la ressource cible (celui ou se 
trouve l'identifiant logique cible) ; 

• trouver dans la base 2 l'URL (adresse physique) correspondant a l'URI trouve a 
l'etape precedente. 

Dans la figure 12-2, l'interpretation de la cible logique se fait a l'exterieur du docu- 
ment, et on suppose que c'est dans une base de donnees. II n'est toutefois pas interdit 
de mettre ces informations en en-tete de document. 

L'utilisation de liens logiques presente de nombreux avantages. Cela augmente la 
flexibilite des systemes contenant un grand nombre de documents XML, la trans- 
portabilite des documents et l'adaptation des liens a des contextes particuliers. 

Dans la section suivante, nous presentons un exemple concret mettant en ceuvre des 
liens logiques. 

Exemple de mise en oeuvre d'un lien logique 

L'exemple que nous utilisons ici est un cas reel. II s'agit d'un modele elabore pour 
gerer des liens a l'interieur d'une publication resultant de l'assemblage de plusieurs 
dizaines de milliers de petits fragments denommes modules. C'est une bonne illus- 
tration du concept presente a la figure 12-2. 

Dans le module suivant, le texte de l'element <p> contient une reference LI a un ele- 
ment "I in kid situe en debut de module. II a pour role de specifier le lien de maniere 
logique : la cible est l'element porteur de l'identifiant i 5 dans le module dont l'iden- 
tifiant logique est e07652. 

<module> 
<"linkld id="Ll"> 

<target id="e07652" type="element">i 5</target> 
</~linkId> 



<p id="pl"> Ce paragraphe contient un lien vers un <link ref="Ll"> 

e"lement</"1ink> d'un autre document. </p> 

</module> 
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Un autre document XML etablit la correspondance entre l'identifiant logique de la 
cible et l'URL de la ressource cherchee. Dans notre exemple, cette ressource est le 
fichier c: /doc/6733. xml : 

<docbase> 
<ressourceId id="L07652" type="entity">e07652</ressourceld> 
<ressource url="file://c:/doc/6733 .xml " ref="L07652"/> 

</docbase> 

La situation peut etre resumee au travers des tableaux 12-1 et 12-2 ci-apres. 
Tableau 12-1 Cheminement logique dans la source du lien 



L1 


Identifiant logique local. 


* 




e07652 


Identifiant logique de la ressource cible. 


15 


Identifiant physique de I'element cible dans la ressource cible. 


Tableau 12-2 Cheminement logique dans le fichier de correspondances 


e07652 


Identifiant logique de la ressource cible. 


* 




L07652 


Identifiant logique interne. 


* 




c:/doc/6733.xml 


Adresse physique de la ressource cible. 



L'identifiant physique i 5 de I'element XML aurait egalement pu etre un identifiant 
logique. Son processus de transposition aurait alors suivi un schema similaire a celui 
que nous venons de decrire. Cet identifiant aurait egalement pu etre une expression 
Xpointer, recommandation du W3C qui permet de definir une cible au moyen d'une 
expression calculee. 

Nous avons glisse dans le module XML de depart un identifiant pi sur I'element p, 
pour indiquer que cet element peut lui-meme etre une cible de lien. Le cas de deux 
modules XML disposant de liens logiques croises l'un vers l'autre est illustre a la 
figure 12-3. 

Dans cette figure sont representes trois documents XML : deux sont des modules 
nommes modi et mod2, et le troisieme est une base de transposition qui specifie les 
correspondances logique/physique. 

Dans ce schema, la base de transposition sert en quelque sorte de gare de triage des liens. 
Elle prend en charge la mise en relation des sources logiques avec leurs cibles physiques. 
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Figure 12-3 

Exemple de liens croises 
entre deux modules 



<locid="Ll"> 

docorsub-"e07652"' 

element-"p1" 
</loc> 



<p id-"pT'>-*-- 

o 

<hylinkref="L1"; 



<docloc 

-►id="L07651" 

'- entity=e07651 +-- 
</docloc> 
<doc 

url="mod1.xml" 

id="i07651" * 

docloc="L07651">„_ 



<dccloc i 

id="L07652">-«- 

* , entity=e07652*" 

</docloc> 
<doc 

urt="mod2.xml" 

id-" i07653" 
docloc="L07652' 



Base de transposition 



© 



<locid="Ll"> 

docorsub-"e07651"' 

element-"pl" 
</loc> 



<p id-"pl"x 

<hylinkref-"Ll"> 



mod2.xml Q 



On notera que, dans notre exemple, sources et cibles se sont vu attribuer les memes 
identifiants, a savoir LI pour les sources et pi pour les cibles. Avec la technique que 
nous decrivons ici, cela n'est pas genant. 

Les points de depart des liens sont reperes par les marques O et ©. Leurs cibles sont 
les elements reperes par les marques © et O. Le trace en pointille fin indique le 
chemin suivi pour aller de O a ©, tandis que celui figurant en pointille epais montre 
le chemin suivi pour aller de © a O. 

Tous les identifiants logiques des cibles utilises dans les modules sont mis en corres- 
pondance avec une adresse physique dans la base de transposition. Toutefois le meca- 
nisme, comme vous pouvez le voir en suivant les traits en pointille, n'est pas direct et 
passe lui-meme par un jeu de liens internes a la base de transposition : cela afin 
d'eviter qu'une meme adresse physique soit repetee autant de fois qu'il y a de liens 
l'utilisant dans les documents. 

Nous donnons ci-apres la representation concrete de ces trois documents XML : 

Module modl.xml : 



<module> 
<avcorps> 
<1inkld id="Ll"> 

<target id="e07652" type="element">i 5</target> 
</"linkId> 
</avcorps> 
<body> 
<p id="pl"> Ce paragraphe contient un lien vers un <link ref="Ll"> 
e"lement</"link> de document 2.</p> 

</body> 
</module> 



Modeles de reference 

Deuxieme partie 



Module mod2.xml : 

<module> 
<avcorps> 
<"linkld id="Ll"> 

<target id="e07651" type="element">pl</target> 
</"linkId> 
</avcorps> 
<body> 
<p id="i5"> Ce paragraphe contient un Tien vers un <link ref="Ll"> 
e"lement</"link> de document l.</p> 

</body> 
</module> 

Base de transposition : 

<docbase> 

<ressourceId id="L07651" type="entity">e07651</ressourceld > 
<ressourceId id="L07652" type="entity">e07652</ressourceld > 
< res source url="f"Me://c:/doc/modl.xml " ressourceId="L07651"/> 
< res source url="f"Me://c:/doc/mod2 .xml " ressourceId="L07652"/> 

</docbase> 

Nous en profitons pour attirer votre attention sur la difference que nous avons notee 
dans les chapitres 2 et 3 entre les modeles conceptuels et les modeles physiques. Le 
modele conceptuel indique la semantique des liens qui sont mis en jeu dans le 
modele, comme l'indique la figure 12-4 : 



Figure 12-4 

Exemple de modele conceptuel 
representant le lien entre les 
entites module et paragraphe 



Module 



0..1 



o- 



refParagraphe 



Paragraphe 



L'association de composition indique que le modele physique XML utilisera vrai- 
semblablement le mecanisme d'emboitement des elements XML, ce qui est le cas 
dans notre exemple. Rien n'est dit, en revanche, sur le mode d'implementation phy- 
sique de l'association de referencement de paragraphe. 

On pourrait faire un modele de classe de l'implementation des liens de reference ; 
mais il se situerait de facto sur un autre plan conceptuel que le modele represente a la 
figure 12-4. 
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Cas extreme 



Dans certains cas, la totalite du contenu d'un document est stockee a l'exterieur du 
document. II n'est alors plus qu'un lieu de rassemblement des liens utilises pour col- 
lecter 1'information au moment de sa publication. 

Un tel document n'est finalement constitue que de liens vers la matiere stockee a 
l'exterieur : des mots, phrases, paragraphes, illustrations, icones, etc. 

Ces liens viennent se superposer aux autres et forment un ensemble que nous avons 
represente a la figure 12-5. II s'agit precisement des liens reliant la couche intitulee 
« documents abstraits » a la couche « contenu physique ». 



Figure 12-5 

Documents abstraits 
composes de liens 
logiques etde liens 
vers le contenu 



Liens Logiques 



Documents abstraits 



Contenu physique 




Ces documents abstraits ont cet avantage, de toute evidence, qu'ils sont extremement 
souples, notamment en matiere de mises a jour, de traductions, d'adaptations. lis ne 
peuvent toutefois exister que dans un monde parfaitement modelise et structure. 

Nous ne rentrerons pas ici dans le detail de tels cas d'utilisation extremes, dont les 
problemes de prise en compte relevent bien plus du domaine de la gestion que de 
celui de la mecanique des liens. 



Liens simples de type ID/IDREF 

Les liens simples de type ID/IDREF existent en XML 1.0 et perdurent en 
XML Schema simplement pour assurer la compatibilite ascendante de XML. 
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Le type ID (comme IDentifiant) attribue a un element un identifiant unique. Un 
exemple deja utilise dans la section precedente est <p id="pl">. L'identifiant pi est 
ici attribue a l'element p au moyen de l'attribut i d. Ni la valeur pi ni le nom de 
l'attribut id n'est impose(e), bien evidemment. Le type ID est devolu a l'attribut id 
lors de sa definition dans la DTD. 

Le type IDREF (comme REFerence d'IDentifiant) permet de referencer un identi- 
fiant unique ; par exemple en ecrivant <ref idref="pl"/>. La encore, ni le nom de 
l'attribut id ref ni sa valeur n'est impose(e). Le type IDREF est devolu a l'attribut 
i dref lors de sa definition dans la DTD. 

Remarquez que le mecanisme des ID/IDREF ne permet pas autre chose que de faire 
des liens simples, non types et sans definition particuliere de comportement. Une 
limitation majeure des types ID et IDREF est que les sources et cibles sont obliga- 
toirement confinees a I'interieur du meme document XML : 

• La valeur de l'attribut de type ID doit etre unique a I'interieur du document qui la 
contient, et c'est une unicite totale : elle ne peut etre confinee a une partie seule- 
ment du document. 

• La valeur de l'attribut de type IDREF doit etre un identifiant unique du docu- 
ment dans lequel elle se trouve. 

Les autres limitations sont les suivantes : 

• Pas de support des expressions Xpath. 

• Les types ID/IDREF ne sont applicables qua des valeurs d'attributs et non au 
contenu des elements. 

En conclusion de ces limitations, on peut affirmer que le type ID/IDREF est notoi- 
rement insuffisant pour batir une quelconque strategic de gestion des liens au sein 
d'un systeme d'information. 



Lapproche du W3C : XLink 



Introduction 



XLink est la recommandation du W3C qui specifie un vocabulaire pour etablir des 
liens entre des ressources. Ces liens peuvent etre de type simple (point a point) ou 
etendus, c'est-a-dire utilisant des relations typees. 

La recommandation date du 27juin2001 (http://www.w3.org/TR/2001/REC-xlink- 
20010627/). Elle n'a pas ete modifiee a ce jour. 
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Nous allons presenter dans cette section les liens simples et etendus, et nous verrons 
un cas reel de mise en oeuvre. 

Les liens XLink sont definis au moyen d'attributs. Ces derniers doivent etre declares 
dans les DTD et schemas XML pour etre valides. Une fois les liens poses, leur 
semantique est comprise nativement par les logiciels prenant en charge la recom- 
mandation XLink. 

II s'agit de liens de navigation a ne pas confondre avec des liens d'inclusion. Comme 
leur nom l'indique, les liens de navigation servent a naviguer de documents en docu- 
ments, tandis que les liens d'inclusion servent a inclure logiquement des documents 
XML les uns dans les autres : en termes de modeles XML, la difference est de taille 
puisque, dans le premier cas, les schemas doivent seulement cohabiter, tandis que 
dans le second ils doivent etre parfaitement compatibles. 

Afin de rendre explicite la presentation de XLink qui suit, nous allons utiliser un 
exemple dans lequel interviendront des personnes et des liens entre ces personnes : 

Liste des personnes : 

• PI : Mme GR, 

• P2:M. DH, 

• P3:M.JG. 
Liens entre les objets : 

• Rl : « est la mere de », 

• R2 : « est le pere de », 

• R3 : « est la grand- mere de ». 

A partir de ces donnees, on simulera les situations suivantes : 

• P1(I1)-R1-P2(I2) : Madame GR est la mere de monsieur DH. 

• P2(I2)-R2-P3(I3) : Monsieur DH est le pere de monsieur JG. 

• P1(I1)-R3-P3(I3) : Madame GR est la grand-mere de monsieur JG. 

Dans une telle relation de parente, les relations Rl, R2 et R3 ne sont pas definies en 
dur. En revanche, une relation generate unissant deux etres peut etre representee 
ensuite, cas par cas, en precisant le role des personnes dans la relation. On obtient 
ainsi le modele exprime par le tableau 12-3. 





Tableau 12-3 Expression de relations de parente 




Personne 


Role / Personne 


Role 


Madame GR 


Mere 


Relation de parente Monsieur DH 


Fils 


Monsieur DH 


Pere 


Relation de parente 


Monsieur JG 


Fils 


Madame GR 


Grand-mere 


Relation de parente 


Monsieur JG 


Petit-fils 
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Les liens etablis sont alors bijectifs puisque le tableau inverse peut etre deduit tres 
facilement de ces relations. 

Completons le tableau 12-3 en attribuant des proprietes aux personnes ; en l'occur- 
rence, il s'agit de leur date de naissance. On aboutit au tableau 12-4. 





Tableau 12-4 Tableau descriptif complet des associations (liens) de notre 


exemple 




Personne 


Date de 
naissance 


Role / Personne 


Date de 
naissance 


Role 


Madame GR 


19480908 


Mere 


Relation de parente Monsieur DH 


19640316 


Fils 


Monsieur DH 


19640316 


Pere 


Relation de parente Monsieur JG 


19861111 


Fils 


Madame GR 


19480908 


Grand-mere 


Relation de parente Monsieur JG 


19861111 


Petit-fils 

l 



Cet exemple montre : 

• qu'un lien peut etre type, « est le fils de » par exemple est un type de lien ; 

• qu'une meme ressource peut etre alternativement source et cible de liens : son role 
varie ; 

• que les informations doivent etre factorisees pour eviter la duplication. 
Nous allons voir comment XLink traduit ces concepts. 

Revue des elements de XLink servant a specifier des liens 



Modele conceptuel de XLink 

Avant de presenter le detail des possibilites offertes par les attributs definis par 
XLink, nous allons etudier son modele conceptuel (figure 12-6). 

La representation UML offre une vue synthetique des combinaisons offertes par 
XLink. Elle a l'avantage d'etre particulierement simple a lire par rapport aux tableaux 
detailles des sections qui suivent. Les deux types de liens XLink y sont representes 
par les classes ExtendedLink et SimpleLink Un lien etendu est compose de res- 
sources locales (la classe Ressource), d'acces a des ressources distantes (la classe 
Locator) et de relations semantiques entre les ressources (la classe Arc). XLink fait 
done explicitement la difference entre les participants a un lien (les ressources locales 
ou distantes) et les caracteristiques semantiques des relations entres les participants 
(les arcs). II est ainsi possible d'associer plusieurs semantiques a un meme lien. 

Le modele conceptuel fait aussi observer qu'un lien simple regroupe sur un meme 
element les caracteristiques d'un lien etendu : il porte a la fois les caracteristiques 
d'acces a une ressource distante (LocatorType) et les caracteristiques semantiques du 
lien (ArcType). 
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Figure 12-6 

Modele conceptuel 
deXLink 



ArcType 



+arcrole:ArcRole 

+show 

+actuate:actuateValues 



LocatorType 



+hRef:uri 
+role:Role 
+title:Title 



ExtendedLink 



+role:Role 
+title 



+title:TItle 

+actuate:actuateValues 
+arcrole:ArcRole 
+show 



ArcType 



+arcrole:ArcRole 
+show 
+actuate:actuate Values 



T 



remoteResource 


AnyResource 




| hRef:uri | i 



SimpleLink 



+actuate:actuateVal Lies 

+arcrole:ArcRole 

+show 

+hRef:uri 

+role:Role 

+title:Title 



localResource 



+role:Role 
+title:Title 
+lablel:Label 



+hRef:uri 
+role:Role 
+title:Title 
+lablel:I_abel 



I 



TraversedResource 



«Enumeration>> 

actuateValues 



none 

onload 

onrequest 

oilier 



Les paragraphes suivants decrivent le modele XML physique de XLink. Nous dispo- 
sons ainsi d'un autre exemple de transformation entre un modele conceptuel et un 
modele physique. Cette transformation est d'autant plus interessante que XLink 
pousse a l'extreme les techniques d'utilisation d'attributs pour representer la seman- 
tique des elements, tels que nous les avons presentes au chapitre 5, « Finaliser la 
semantique du balisage ». Le modele physique XLink se presente done sous forme 
d'une liste d'attributs a placer sur les elements XML. Les regies de placement de ces 
attributs sont directement issues du modele conceptuel decrit a la figure 12-6. 



Element Xlink de type lien simple 

Le plus basique des liens Xlink est celui de type simple. Ce lien a une source et une 
cible uniques. Les deux exemples qui suivent montrent la forme d'un lien simple. 

Le premier exemple est l'expression la plus simple d'un lien Xlink. Les attributs 
xml ns : xl , xl : type et xl : href declarent respectivement l'espace de noms de Xlink et 
le prefixe xl qui lui est associe, le type de lien et FURL de la cible. 
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<logo xmlns:xl = "http://www.w3.org/1999/xlink" xl : type="simple" 
xl :href="xmldev.gif" /> 

Dans le second exemple, les attributs xl : show et xl : actuate sont utilises. 

<logo xmlns:xl="http://www. w3.org/1999/xlink" xl : type="simple" 
xl :href="xmldev.gif" xl : show="new" xl :actuate="onLoad"/> 

Dans XLink, les elements porteurs de liens simples n'ont pas d'enfant (au sens 
XLink), c'est-a-dire qu'ils n'ont aucun element enfant specifique dont la vocation 
serait de porter des informations complementaires sur la nature du lien. En revanche, 
ces elements peuvent avoir des enfants XML « normaux ». 

Le tableau 12-5 liste les attributs Xlink autorises sur les elements Xlink de type simple. 
Tableau 12-5 Attributs des elements Xlink de type lien simple 



Nom de I'attribut Type ou valeurs Explications 
XLink autorisees 


type 


"simple" 


Cet attribut specifie que le lien est de type simple. 


href 


CDATA 


L'URI de la cible. 


role 


URI 


Fournit I'URI d'une ressource qui indique le role du lien simple. 


arcrole 


URI 


L'URI d'une ressource precisant la fonction du lien. 


title 


CDATA 


Description du lien comprehensible par un etre humain. 


show 


"new" 


Le contenu de la cible s'affiche dans une nouvelle fenetre. 


"replace" 


Le contenu de la cible remplace celui de la fenetre active. 


"embed" 


Le contenu de la cible s'insere dans celui de la fenetre active. 


"other" 


Le type d'affichage n'est pas I'un des trois definis en standard 
mais reste toutefois specifie dans le lien par un balisage. 


"none" 


Le type d'affichage n'est pas I'un des trois definis en standard et 
n'est pas specifie dans le lien par un quelconque balisage. 


actuate 


"onLoad" 


Le lien est active des le chargement du document XML. 


"onRequest" 


Le lien est active par une action volontaire de I'utilisateur. 


"other" 


Le type d'activation n'est pas I'un des deux cas standards mais 
reste toutefois specifie dans le lien par un balisage. 


"none" 


Le type d'activation n'est pas I'un des deux cas standards et n'est 
pas specifie dans le lien par un quelconque balisage. 



Le lien simple est comparable aux mecanismes des ID/IDREF de SGML et XML, 
et a 1' element <a href=" . . . "> de HTML. 
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Element Xlink de type etendu (ou extended) 

L' element Xlink de type lien etendu permet de gerer des liens plus sophistiques que 
le lien simple. II s'agit notamment de ceux dont la cible est definie de maniere 
logique, mais il peut s'agir plus simplement d'un lien pointant sur plusieurs cibles. 

Un lien etendu permet d'associer autant de ressources que necessaire. 

Quand les ressources associees par le lien sont locales, on les definit a l'aide d'ele- 
ments de type « ressource », tandis que dans le cas ou elles sont distantes, on les 
definit a l'aide d'elements de type « localiseur ». 

D'une maniere generale, l'element de type etendu s'accompagne des elements enfants 
de types « localiseur », « arc », « ressource » et « titre ». 

Nous donnons ci-apres un exemple de lien etendu. 

<extendedl ink xml ns : xl ="http : //www. w3 . org/1999/xl i nk" 
xl :type="extended"> 

<ressource-locale xl : type="resource"> 
n'importe quel contenu ou vide 
</ressource-locale> 

<ressource-distante xl :type="locator" xl :href="http: //www. dev.com/ 
index.html "> 

Attribut href obligatoi re sur element de type locator et l'element 
parent doit it re de type extended 
</ressource-di stante> 
</extendedlink> 

Le tableau 12-6 liste les attributs autorises sur les elements Xlink de type etendu. 
Dans notre exemple, nous pourrions par exemple avoir : 

<extendedl ink xml ns : xl ="http : //www. w3 . org/1999/xl i nk" 

xl :type="extended" role=" http://www.dev.com/indexDescription. html " 

title="Lien entre un index et un mot"> 

Dans cet exemple, on est cense trouver a l'URI specifie par l'attribut rol e une des- 
cription comprehensible par l'application du role du lien. 

Tableau 12-6 Attributs des elements Xlink de type etendu 



Norn de l'attribut Type ou valeurs Explications 
XLink autorisees 


type 


"extended" 


Cet attribut specifie que le lien est de type etendu. 


role 


URI 


Fournit l'URI d'une ressource renseignant sur le role du lien etendu. 


title 


CDATA 


Description comprehensible de l'element de type lien etendu. 
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Element Xlink de type ressource 

Les elements de type ressource servent a definir des ressources locales, a priori desti- 
nees a participer a un lien etendu. 

Les ressources locales sont principalement identifiees grace a un label, ou identifiant 
unique. 

Les ressources locales n'ont pas d'element Xlink enfant particulier. 

Le tableau 12-7 liste les attributs autorises sur les elements Xlink de type ressource. 

Tableau 12-7 Attributs des elements Xlink de type ressource 



Nom de I'attribut Type ou valeurs Explications 
XLink autorisees 


type 


"resource" 


Cet attribut specifie que le lien est de type « resource ». 


role 


URI 


URI ou Ton pourra trouver le role de la ressource locale. 


title 


CDATA 


Description comprehensible de la ressource locale. 


label 


NCName 


Identifiant unique de la ressource. 



Void un exemple de ressource locale, qui appelle un graphique au moyen d'un lien 
simple : 

<figure xl :type=" resource" xl : label ="fig001" 

xml ns : xl ="http : //www . w3 . org/1999/xl i nk"> 
<legende>LH Multifunction Head Down Display</legende> 
<graphic xl :type="simple" 

xl :href="ICN-lB-B-311501-B-K0999-00352-A-01-l.CGM" 

xl :actuate="onLoad xl :show="embed"/> 
</figure> 

Element Xlink de type localiseur (ou locator) 

Les elements de type localiseur servent a specifier les adresses des ressources distantes 
qui participent a un lien. 

Le tableau 12-8 liste les attributs autorises des elements Xlink de type localiseur. 
Tableau 12-8 Attributs des elements Xlink de type localiseur 



Nom de I'attribut Type ou valeurs Explications 
XLink autorisees 


Type 


"Locator" 


Cet attribut specifie que le lien est de type localiseur. 


Role 


URI 


URI ou Ton pourra trouver le role de la ressource distante. 


Title 


CDATA 


Description comprehensible du localiseur. 
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Tableau 12-8 Attributs des elements Xlink de type localiseur 



Norn de I'attribut Type ou valeurs Explications 
XLink autorisees 


Label 


NCName 


Identifiant du localiseur. 


Href 


URI 


Attribut obligatoire qui fournit I'URI d'une ressource dite distante. 



Cet element accepte un seul enfant Xlink : celui de type ti tl e. 

On pourrait souhaiter transformer en element de type localiseur l'exemple de type 
ressource precedent, ce qui donnerait : 

<figure xl : type=""locator" xl : label ="fig001" xmlns :xl="http:// 
www.w3.org/1999/xlink" 

xl :href="ICN-lB-B-311501-B-K0999-00352-A-01-l.CGM"> 
<legende xl :type="title">LH Multifunction Head Down Display</legende> 
</figure> 

Dans cet exemple, nous avons transforme la combinaison d'une ressource et d'un lien 
simple en un seul lien element de type localiseur. On a simplifie le balisage, mais au 
detriment de la possibilite de specifier directement le comportement que 1' applica- 
tion doit avoir au moment de l'activation du lien : on a en outre la possibilite de spe- 
cifier les attributs xl : actuate et xl : show. 



Element Xlink de type arc 

L'element de type arc sert a definir une relation entre deux ressources, locales ou dis- 
tantes, et done de type ressource ou localiseur. La relation est definie par trois 
elements : un type, une source et une cible. Dans une relation, la source et la cible 
jouent chacune un role par rapport a la nature de la relation (e'est ce qui va nous per- 
mettre d'exprimer les differents cas de figure des exemples presentes au tableau 12-4). 

Void un premier exemple de mise en ceuvre d'un element de type arc, dans lequel on 
voit bien les notions de type de relation et de role des source et cible : 

<rel ati on xml ns : xl =http : //www. w3 . org/1999/xl ink 

xl :type="arc" 

xl :f rom="zeus" 

xl : to="heracles" 

xl :arcrole="fils"/> 
<god xl : href="greece/gods/gods .xml#god[@name='zeus' ] " 

xl :label="zeus" 

xl : role="dieu grec" 

xl :title="Zeus" 

xl :type="locator"/> 
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<god xl : href="greece/gods/gods . xml#god[@name=' heracles'] " 
xl :label="heracles" 
xl : role="demi-dieu grec" 
xl :title="Heracles" 
xl :type="locator"/> 

Le tableau 12-9 liste les attributs autorises des elements Xlink de type arc. 

Tableau 12-9 Attributs des elements Xlink de type arc 



Nom de I'attribut Type ou valeurs Explications 


type 


"arc" 


Cet attribut specifie que le lien est de type arc. 


arcrole 


URI 


Le role de la ressource ciblee par I'attribut to dans Tare 


title 


CDATA 




show 


"new" 


Le contenu de la cible s'affiche dans une nouvelle fenetre. 


"replace" 


Le contenu de la cible remplace celui de la fenetre active. 


"embed" 


Le contenu de la cible s'insere dans celui de la fenetre active. 


"other" 


Le type d'affichage n'est pas I'un des trois definis en standard, mais 
reste toutefois specifie dans le lien par un balisage. 


"none" 


Le type d'affichage n'est pas I'un des trois definis en standard et 
n'est pas specifie dans le lien par un quelconque balisage. 


actuate 


"onLoad" 


Le lien est active des le chargement du document XML. 


"onRequest" 


Le lien est active par une action volontaire de I'utilisateur. 


"other" 


Le type d'activation n'est pas I'un des deux cas standards mais reste 
toutefois specifie dans le lien par un balisage. 


"none" 


Le type d'activation n'est pas I'un des deux cas standards et n'est pas 
specifie dans le lien par un quelconque balisage. 


from 


NCName 




to 


NCName 


Le label d'une ressource locale ou element de type localiseur. 



Cet element accepte un seul enfant Xlink : celui de type ti tl e. 

Element Xlink de type titre (ou title) 

L'element de type titre permet d'exprimer des labels lisibles et comprehensibles par 
l'ceil humain, nous permettant ainsi de reconnaitre lorsqu'ils sont affiches, le type du 
lien ou de la ressource, consulte ou active. 

Le tableau 12-10 liste les attributs autorises des elements Xlink de type titre. 

Cet element n'admet pas d'autre element Xlink enfant. 
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Tableau 12-10 Attributs des elements Xlink de type titre 


Nom de I'attribut 
XLink 


Type ou valeurs Explications 
autorisees 


type 


"title" Cet attribut specifie que le lien est de type titre. 



Exemple de mise en oeuvre de XLink 



Lien de type simple 

Dans la version XML Schema de la norme S1000D, deja presentee plusieurs fois 
dans les chapitres precedents, les liens a des ressources externes sont de type XLink. 

Les ressources externes sont des fichiers graphiques, des modules XML et des publi- 
cations. 

Dans l'exemple ci-apres, un lien Xlink est etabli avec un module XML. II s'agit d'un 
lien simple utilisant l'URI du module cible (via I'attribut xl : href) egalement accom- 
pagne de la definition logique de ce module (via 1' element avee) : 

<refdm xmlns:xl="http://www.w3 . org/1999/xlink" 

xl : type="simple" 

xl :actuate="onRequest" 

xl : show=" replace" 

xl : title="Interactive Electronic Technical Publications - 
*XML-oriented (IETP-X)" 

xl : href=" http://www.aecma.org/Publications/SpeclOOOD/ 
*-DMC-AE-A-00-40-05-50A-OOOA-A.XML"> 
<avee> 

<model i c>AE</model i c> 
<sdc>A</sdc> 
<chapnum>00</chapnum> 
<secti on>4</secti on> 
<subsect>0</subsect> 
<subject>05</subject> 
<di scode>50</di scode> 
<di scodev>A</di scodev> 
<i ncode>000</i ncode> 
<i ncodev>A</i ncodev> 
<i teml oc>A</i teml oc> 
</avee> 
</refdm> 
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Dans ce premier exemple, on remarquera que le lien simple porte sur l'ensemble du 
bloc de donnees avee et non sur un seul de ces elements. D'ou l'interet de decrire un 
lien simple sur un element qui peut lui-meme contenir d'autres elements. 

Le deuxieme exemple montre un lien vers une illustration ou Ton retrouve un meca- 
nisme similaire de double identification de la cible : physique au travers de l'attribut 
xl : href et logique au travers de l'attribut boardno : 

<figure id="fig001"> 

<title>LH Multifunction Head Down Display</title> 

<graphic xmlns:xl="http: //www. w3.org/1999/xl ink" xl : type="simple" 

xl :href="ICN-lB-B-311501-B-K0999-00352-A-01-l.CGM" 

xl :actuate="onLoad" 

xl : show="embed" 

boardno="ICN-lB-B-311501-B-K0999-00352-A-01-l"/> 
</figure> 

Dans cet exemple, la seule utilite du double lien est qu'il fournit simultanement les 
adresses physique et logique d'une illustration. Cette redondance peut sembler inu- 
tile mais, dans la pratique, il est souvent utile de dissocier les identifiants logiques 
d'illustrations des adresses physiques des fichiers les contenant, un peu a la maniere 
de ce qui a ete presente en debut de chapitre. 

Le principe est le meme pour cibler un element particulier a l'interieur d'un module 
de donnees. Dans 1' exemple suivant, on cible i'element dont i'identifiant est 
CSN-53251001-OOl-OOA: 

-ccsnref xmlns:xl=" http://www.w3.org/1999/xl ink" 
xl : type="simple" 

xl :href="DMC-Al-A-53-25-10-010-941A-A 003.XML* 
CSN-53251001-OOl-OOA" 

xl :actuate="onRequest" 
xl :show="new" 
refcsn="53251001 001" 
refisn="OOA"/> 

Lien de type complexe 

Le cas pratique presente au tableau 12-4 sera exprime par des liens XLink de type 
arc. Dans 1' exemple presente ci-apres, les elements personne, objet et relation ne 
font pas partie du vocabulaire de XLink. Quant au prefixe xl , c'est celui habituelle- 
ment associe a l'espace de noms de Xlink. 
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<personne id="gr" naissance="19480908">Mme Gertrude R</personne> 
<personne id="dh" naissance="19640316">Mr Denis H</personne> 
<personne id="jg" naissance="19861111">Mr Jerome C</personne> 

<lienparent xl :type="simple" role=" relation de filiation"> 
<part xl :type="locator" xl :label="gertrude" role="proche" 

xl :href="#personne[@id='gr' ] "/> 
<part xl : type="locator" xl :label="denis" role="proche" 

xl :href="#personne[@id='dh' ] "/> 
<relation xl :type="arc" xl :f rom="gertrude" xl :to="denis" 

xl :arcrole="fils"/> 
<relation xl :type="arc" xl :f rom="denis" xl :to="gertrude" 
xl :arcrole="mere"/> 
</lienparent> 

<lienparent xl :type="simple" role=" relation de filiation"> 
<part xl : type="locator" xl :label="denis" role="proche" 

xl :href="#personne[@id='dh' ] "/> 
<part xl : type="locator" xl :label="jerome" role="proche" 

xl :href="#personne[@id=' jg' ] "/> 
<relation xl :type="arc" xl :f rom="denis" xl :to="jerome" 

xl :arcrole="fils"/> 
<relation xl :type="arc" xl :from=" Jerome" xl : to="denis" 
xl :arcrole="pere"/> 
</lienparent> 

<lienparent xl :type="simple" role=" relation grandparentale"> 
<part xl :type="locator" xl :label="gertrude" role="proche" 

xl : href="#personne[@id='gr' ] "/> 
<part xl : type="locator" xl :label="jerome" role="proche" 

xl : href="#per sonne [@id=' jg' ] "/> 
<relation xl :type="arc" xl :f rom="gertrude" xl :to="jerome" 

xl :arcrole="petit-fils"/> 
<relation xl :type="arc" xl :from=" Jerome" xl : to="gertrude" 
xl :arcrole="grand-mere"/> 
</lienparent> 

On pourrait tout aussi bien creer un seul lien complexe comme indique ci-apres. 

<lienparent xl :type="simple" role=" relation de parente"> 
<part xl :type="locator" xl :label="gertrude" role="proche" 

xl :href="#personne[@id='gr' ] "/> 
<part xl : type="locator" xl :label="denis" role="proche" 

xl :href="#personne[@id='dh' ] "/> 
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<part xl : type="locator" xl :label="jerome" role="proche" 

xl :href="#personne[@id=' jg' ] "/> 
<relation xl :type="arc" xl :f rom="gertrude" xl :to="denis" 

xl :arcrole="fils"/> 
<relation xl :type="arc" xl :from="denis" xl :to="gertrude" 

xl :arcrole="mere"/> 
<relation xl :type="arc" xl :from="denis" xl :to="jerome" 

xl :arcrole="fils"/> 
<relation xl :type="arc" xl :from=" Jerome" xl :to="deni s" 

xl :arcrole="pere"/> 
<relation xl :type="arc" xl :f rom="gertrude" xl :to=" Jerome" 

xl :arcrole="petit-fils"/> 
<relation xl :type="arc" xl :from=" Jerome" xl :to="gertrude" 

xl :arcrole="grand-mere"/> 
</lienparent> 

On peut observer que nous avons ici un document XML traduisant parfaitement les 
associations souhaitees, mais que seul un programme peut pratiquement exploiter. 
En l'occurrence, il faut remarquer que ni ce document XML ni son schema associe 
ne peuvent exprimer la semantique preconisee par leur auteur. Seule la representation 
UML du modele conceptuel peut transmettre cette information. 



L'approche de 1'ISO : le modele Topics Map 

Dans cette section, nous presentons la specification XTM (XML Topics Map), qui 
est une proposition de vocabulaire XML pour les Topics Maps, ou cartes de topi- 
ques, qui fait l'objet de la norme ISO 13250 de 2000. Les cartes de topiques sont des 
ensembles de ressources hautement interconnectees entre elles par des faisceaux de 
relations. II s'agit d'un modele de liens qui adresse un niveau superieur a Xlink, et, a 
ce titre, englobe cette recommandation du W3C. 



Specification XTM XML Topics Map 

Produit par TopicMaps.Org, le texte originel se trouve a I'URL http://www.topicmaps.0rg/xtm/l .0/ 
xtml -2001 0806.html et sa version frangaise est hebergee par XMLfr.org (http://www.xmlfr.org). 



XTM propose un modele qui est apprecie de ceux qui travaillent dans les mondes de 
l'edition, de la documentation, des bibliotheques, de l'industrie et de la gestion des 
connaissances. II apparait comme plus concret, pragmatique et facile a mettre en 
ceuvre que RDF ; il est vrai qu'il beneficie d'une experience du terrain superieure de 
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plusieurs annees a celle qui accompagne RDF, et que ses concepteurs ne viennent pas 
du monde de 1'intelligence artificielle mais de celui des documents ou naquirent aussi 
la plupart des modeles operationnels ayant trait a la structuration de 1'information. 
En void un bref historique : 

• 1985 : Ch. Goldfarb lance une serie de travaux sur la description structuree et 
synchronised de la musique, travaux connus sous le nom de Standard Music Des- 
cription Language, acronyme SMDL. De ces travaux emergerent les concepts et 
formulations concretes des liens hypermedias. 

• 1991 : le groupe de travail Davenport commence les travaux sur le standard Sofa- 
bed (Standard Open Formal Architecture for Browsable Electronic Documents). 

• 1992 : naissance de la norme ISO HyTime (Hypermedia Time based Structuring 
Language - ISO 10744). Elle etablit un modele de liens hypertextuels internes et 
externes aux documents dont les extremites peuvent etre de nature et de granula- 
rite diverses. HyTime permet egalement d'exprimer des contraintes de synchroni- 
sation temporelle entre des evenements de type video, son, sequences photos... 

• 1994 : HyTime, trop complexe a mettre en oeuvre tel quel, donne lieu a l'ecriture 
de conventions d'application simplifies baptisees CApH (Conventions for the 
Applications of HyTime). Conduits par Steve Newcomb et Michel Biezunski, 
ces travaux sont a la base de l'invention de Topics Map. 

• Octobre 1996, formation d'un groupe de travail sur Topics Map au sein de 1'ISO, 
qui aboutit au standard ISO/IEC 13250 en Janvier 2000. Le standard repose sur 
SGML et utilise les formes architecturales de HyTime. La syntaxe HyTime con- 
crete utilisee dans Topics Map est baptisee HyTM, pour HyTime Topics Map. 

• Decembre 2001 : la version XML de Topics Map devient une norme ISO. Cette 
version XML ne se contente pas de formuler un modele conforme a XML 1.0, 
mais encore specifie l'adressage des elements externes au moyen d'URI. D'autres 
differences, notamment de structure des modeles de contenu, font que les instan- 
ces HyTM et les documents XTM sont incompatibles. Un convertisseur est 
necessaire pour passer de l'un a 1' autre. 

Un des points les plus interessants de la serie des standards HyTime et Topics Map 
est 1'utilisation de formes architecturales, concept qui consiste a proposer des vocabu- 
laires XML generiques destines a etre embarques dans d'autres. La semantique de 
ces vocabulaires l'emporte alors sur la forme XML physique : XTM, par exemple, est 
l'expression physique des formes architecturales definies par Topics Map. 

Le concept de cartes de topiques, traduction francaise de Topics Map, repose sur une 
separation nette operee entre le fait de relier des elements entre eux et celui de les loca- 
liser. Nous avons deja explique ce concept dans ce chapitre. Cela a pour effet principal 
de rendre la pose de liens totalement independante des supports physiques, permettant 
ainsi d'obtenir des milliers de vues differentes d'une meme base de connaissances. 
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Breve description 

Les cartes de topiques sont comme les cartes routieres : les villes y sont remplacees par 
des topiques et les routes par des relations. Les topiques ont des caracteristiques qui 
permettent de les identifier, et les relations sont typees. La comparaison avec les cartes 
routieres est, a ce stade, tres aisee. La mise en oeuvre est un peu plus complexe car les 
topiques et les relations sont, dans la vie reelle, polymorphes : leur sens peut varier en 
fonction d'un contexte. lis sont abstraits et se situent dans un espace virtuel a 
n dimensions. La comparaison avec les cartes routieres ne peut, sur ce point, perdurer. 



VOCABULAIRE Topiques 

En francais, un topique est un sujet mis dans un contexte. Par exemple, il est plus elegant, en introduc- 
tion d'une intervention publique, de presenter ses topiques plutot que ses sujets. On aurait pu traduire 
Topics Map par carte de sujets, mais il est plus juste d'utiliser I'expression carte de topiques, justement 
parce que, dans le concept developpe par la norme Topics Map, le sens exact des sujets depend de leur 
contexte d'utilisation. II s'agit done bien de topiques. 



VOCABULAIRE Topique, sujet et reif ication 

Comme nous I'avons dit, un topique est un sujet mis dans un contexte. II est done possible d'isoler d'un 
cote des sujets et de I'autre des topiques. Quand on met un sujet dans un certain contexte, il devient un 
topique : on dit que le sujet est reifie. La reification est un processus important du concept de carte de 
topiques. Nous ne nous etendrons toutefois pas dessus dans ce chapitre. Pour plus de precision, referez- 
vous a la version francaise ou anglaise de la specification XTM que vous trouverez respectivement aux 
adresses XMLfr.org et http://www.topicmaps.0rg/xtm/l.O/xtml -2001 0806.html. 



Une des originalites de Topics Map est que tout y est topique, y compris les rela- 
tions. Nous aurons l'occasion de revenir sur ce point. 

Dans i'exemple suivant, trois topiques sont definis (reperes ©, O et ©) : 

<?xml version="1.0" ?> 

<topi cMap xml ns=" http : //www . topi cmaps . org/xtm/1 . 0/" 
xml ns : xl ="http : //www . w3 . org/1999/xl i nk"> 
<topic id="fami11e"> <- © 
<baseName> 

<baseNameString>Fam"Nle</baseNameString> 
</baseName> 
</topic> 

<topic id="personne"> <- O 
<baseName> 

<baseNameStri ng>Personne</baseNameStri ng> 
</baseName> 
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</topic> 

<topic id="jean-chauveau"> <- © 
<instanceOf> 

<topicRef xl : href="#personne"/> ^~ © 
</instanceOf> 
<baseName> 

<baseNameStri ng>Jean chauveau</baseNameStri ng> 
</baseName> 
</topic> 
</topicMap> 

Le topique © est defini comme etant une instance du O via l'element i nstanceOf . Cette 
relation indique que le topique connu grace a l'identifiant Dean Chauveau fait egalement 
partie de la classe de ceux connus via l'identifiant Personne. On voit que le mecanisme 
de referencement des topiques (repere ©) s'appuie sur un lien Xlink de type simple. 

Dans notre exemple, le topique Personne ne fait pas reference a un autre sujet (le 
chainage des topiques devant bien s'arreter un jour !) ; son seul topique parent est la 
classe des topiques generiques. Ce topique se trouve ainsi etre a la tete de tous les 
topiques obtenus par instanciation de ce topique (via l'element i nstanceOf). C'est 
ainsi que se definissent des classes de topiques. 

Topics Map permet d'associer des topiques, dans ce cas appeles ancres, en suivant 
des relations logiques. Les topiques ainsi associes ne sont pas obligatoirement inter- 
changeables (par exemple, si a est le fils de b, l'inverse n'est evidemment pas vrai). 
Pour chaque association, les topiques jouent un role particulier. 

Topics Maps tient compte de ce que les choses peuvent etre exprimees de differentes 
manieres, par exemple : le 16 e siecle, le XVF Steele et la Renaissance sont trois titres de 
topiques representant la meme epoque historique. 

Les concepts developpes par Topics Map peuvent etre utilises pour representer des 
index, des glossaires, des references croisees. Ainsi, un glossaire est constitue d'ancres 
associees deux par deux : un mot ou une expression (une premiere ancre) est associe a 
une definition (une seconde ancre) par une relation de type elements de glossaire. 

Relation entre topiques et ressources physiques 

II est inutile de definir des ressources logiques et des cartes de topiques si, au bout du 
compte, on ne tombe pas sur un objet bel et bien concret ; quand on cherche un texte 
de loi, on souhaite, au terme de la recherche, aboutir soit au texte de loi lui-meme, 
soit a un texte explicatif si seule la version papier du texte existe (par exemple). 
Topics Map permet de faire la distinction entre : 
• une ressource informatique accessible qui est alors 1' objet terminal du topique ; 



Modeles de reference 

Deuxieme partie 



• une ressource physique inaccessible de maniere informatique qui oblige a passer 
par une ressource derivee. 

Topics Map decrit ainsi des objets du monde reel, par exemple un sapin. II est evi- 
demment impossible de mettre physiquement l'arbre dans l'ordinateur, il faudra uti- 
liser des ressources palliatives telles qu'une page Web, une photo ou, plus generale- 
ment, les objets dans lesquels cet arbre apparait ou est cite. Cela peut aussi bien etre 
les coordonnees geodesiques du sapin en question ! 

En revanche, si le sujet decrit une ressource telle qu'un manuel de reparation, alors il 
est a peu pres certain que le document electronique correspondant sera accessible 
informatiquement, et la ressource associee au sujet sera ce document informatique. II 
s'agit d'une ressource terminale. 

Nous donnons un exemple ci-apres de ces deux cas de figure. 

Tout d'abord, voyons celui de la ressource terminale. L' element ResourceRef est uti- 
lise pour en fournir l'URI : 

<subjectldentity> 

<ResourceRef xl : href=" http://www.chau veau.com/genealogie/ jean. html "/> 
</subjectIdentity> 

II ne peut y avoir qu'une seule ressource terminale par topique. 

Ensuite, examinons celui de la ressource derivee ; l'element subjectlndi catorRef est 
utilise pour designer la ressource : 

<subjectldentity> 
<subjectlndi catorRef 

xl :href=" http://www.fami lies . com/chauveau/i ndex.html "/> 
<subjectlndi catorRef 

xl :href="http: //www. opera. com/rouen/chanteurs/index. html "/> 
</subjectIdentity> 

Dans ce cas, il peut y avoir plusieurs ressources derivees. 

Les deux types de ressources peuvent etre combines autant que necessaire, et notre 
exemple pourrait etre : 

<?xml version="1.0" ?> 

<topi cMap xml ns=" http : //www . topi cmaps . org/xtm/1 . 0/" 
xml ns : xl ="http : //www . w3 . org/1999/xl i nk"> 
<topic id="personne"> 
<baseName> 
<baseNameStri ng>Personne</baseNameStri ng> 



Modeles pour la gestion des liens 

Chapitre 12 



</baseName> 
</topic> 

<topic id="jean-chauveau"> 
<instanceOf> 

<topicRef xl : href="#personne" /> 
</instanceOf> 
<subjectldentity> 
<subjectlndi catorRef 

*»xl :href="http: //www. families . com/chauveau/i ndex.html "/> 
<subjectlnd"i catorRef 

xl : href=" http://www.ope ra.com/rouen/chanteurs/index. html "/> 
<resourceRef xl : href="http://www. chauveau . com/genealogie/ jean. html "/> 
</subjectIdentity> 
<baseName> 

<baseNameStri ng>Jean Chauveau</baseNameStri ng> 
</baseName> 
</topic> 
</topicMap> 

Les associations de topiques 

Les topiques pouvant eux-memes etre des liens, le fait d'associer certains topiques 
entre eux consiste a etablir des liens de liens. Ce faisant, on s'apercoit qu'il est pos- 
sible de definir son propre faisceau de liens independamment (ou presque) des topi- 
ques originels. Plus exactement, il est possible de definir ses propres relations sans 
etre aucunement contraint par la definition initiale que le topique exprime. 

Dans l'exemple suivant, les topiques jean-chauveau et operaRouen sont associes par 
la relation est-membre. lis y jouent respectivement les roles definis par les topiques 
chanteur et choeurs. 

ossociation id="est-membre"> 
<instanceOf> 

<topicRef xl :href="#est-chanteur"/> 
</instanceOf> 
<member> 
<roleSpec> 

<topicRef xl :href="#chanteur"/> 
</roleSpec> 

<topicRef xl :href="#jean-chauveau"/> 
</member> 
<member> 
<roleSpec> 
<topicRef xl : href="#choeurs"/> 
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</roleSpec> 

<topicRef xl :href="#operaRouen"/> 
</member> 
</association> 

Et, pour que notre association fonctionne, il faut declarer les topiques qui s'y trou- 
vent utilises : 

<?xml version="1.0" ?> 

<topi cMap xml ns=" http : //www . topi cmaps . org/xtm/1 . 0/" xml ns : xl ="http : // 
www.w3.org/1999/xlink"> 
<topic id="personne"> 
<baseName> 

<baseNameStri ng>Personne</baseNameStri ng> 
</baseName> 
</topic> 

<topic id="jean-chauveau"> <- © 
<instanceOf> 

<topicRef xl : href="#personne" /> 
</instanceOf> 
<subjectldentity> 
<subjectlndi catorRef xl : h ref=" http : //www. f ami lies. com/chauveau/ 
index. html "/> 

<subjectlndi catorRef xl : href=" http: //www. ope ra.com/rouen/chanteurs/ 
index.html "/> 

<ResourceRef xl :href=" http: //www. chauveau.com/genealogie/ jean. html "/ 
> 

</subjectIdentity> 
<baseName> 

<baseNameStri ng>Jean Chauveau</baseNameStri ng> 
</baseName> 
</topic> 

<topic id="chanteur"> 
<baseName> 

<baseNameStri ng>Chanteur</baseNameStri ng> 
</baseName> 
</topic> 

<topic id="choeurs"> <- O 
<baseName> 

<baseNameStri ng>Choeurs d ' opera</baseNameStri ng> 
</baseName> 
</topic> 

<topic id="opera"> 
<baseName> 
<baseNameStri ng>Opera</baseNameStri ng> 
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</baseName> 
</topic> 

<topic id="operaRouen"> 
<instanceOf> 

<topicRef xl :href="#opera" /> 
</instanceOf> 
<baseName> 
<baseNameString>Opera de rouen</baseNameString> 
</baseName> 
</topic> 

<topic id="est-choriste"> <- © 
<baseName> 

<baseNameString>Est membre de</baseNameStn'ng> 
</baseName> 
<baseName> 
<scope> 

<topicRef xl :href="#choeurs"/> <- O 
</scope> 

<baseNameStri ng>Un choeur</baseNameStri ng> 
</baseName> 
<baseName> 
<scope> 

<top"icRef xl :href="#chanteur"/> <- © 
</scope> 
<baseNameStri ng>Un chanteur</baseNameStri ng> 
</baseName> 
</topic> 

<association "id="jean-chauveau-est-choriste-de"> <- © 
<instanceOf> 

<topicRef xl : href="#est-choriste"/> 
</instanceOf> 
<member> 
<roleSpec> 

<topicRef xl :href="#chanteur"/> 
</roleSpec> 

<topicRef xl : href="#jean-chauveau"/> 
</member> 
<member> 
<roleSpec> 

<top"icRef xl :href="#choeurs"/> 
</roleSpec> 

<topicRef xl : href="#operaRouen"/> 
</member> 
</association> 
</top"icMap> 
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Ainsi, on associe (©) deux topiques (©et O) selon une relation (©), elle-meme 
definie par des topiques (O et ©). 

Nous parvenons a un stade ou une representation graphique s'impose. La figure 12-7 
montre le schema de relations que notre Topics Map exprime sous forme XML. 



Figure 12-7 

Representation graphique 
de la carte de topiques 
de notre exemple 
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En clair, voici ce que signifie, dans cet exemple, notre carte de topiques 
(Topics Map) : 

• Le sujet Jean Chauveau est une instance du sujet Personne. 

• Le sujet Opera de Rouen est une instance du sujet Opera. 

• Le sujet Jean Chauveau permet d'acceder a trois ressources physiques. 

• Le sujet Est membre de associe Un chanteur et Un choeur, qui doivent etre res- 
pectivement des topiques des classes Chanteur et Chceur d' opera. 

• Le sujet Jean Chauveau est associe au sujet Opera de Rouen au moyen du sujet 
Jean Chauveau est membre de. Cette association est une instance du sujet 
Est membre de. Sa definition nous permet de savoir que, dans ce cas present, 
Jean Chauveau joue le role d'Un chanteur, et Opera de Rouen celui d'Un chceur. 

Jusqu'a present, nous avons pu classer nos topiques et creer entre eux des relations. 
Les topiques et les associations peuvent etre instancies. Nous verrons a la section sui- 
vante le troisieme et dernier concept intervenant dans une carte de topiques : celui 
d'occurrence de topiques. 
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VOCABULAIRE Instancier 

Une definition communement admise est : « verbe transitif, creer une instance d'une classe, c'est-a- 

dire un objet » (reference : Le Jargon franqais — dictionnaire d'informatique francophone — http:// 

www.linux-france.org/prj/jargonf/l/instancier.html). 

La definition officielle a retenir est celle etablie en 2002 dans le grand dictionnaire terminologique de 

I'Office quebecois de la langue francaise : « En programmation orientee objet, creer a partir d'une classe 

une occurrence de cette classe, heritant par defaut des attributs de sa classe, et qui peut etre dotee 

d'attributs specifiques » (http://www.granddictionnaire.com). 



Les occurrences de topiques 

La notion d'occurrence est tees proche de celle deja mentionnee de referencement de 
ressources physiques via les elements subjectlndicatorRef et ressourceRef. 

La difference tient a ce que le concept d'occurrence indique en plus la nature du sup- 
port physique reference, precisement en referencant un topique... 

Par exemple, pour indiquer que Dean Chauveau apparait sur une photo disponible en 
ligne dont le nom de fichier est JC1921 . gi f , on ecrira : 

<topic id="jean-chauveau"> 
<instanceOf> 

<topicRef xl :href="#personne" /> 
</instanceOf> 
<subjectldentity> 
<subjectlndi catorRef 

•»xl :href="http: //www. families . com/chauveau/i ndex.html "/> 
<subjectlndi catorRef 

xl : href=" http: //www. ope ra.com/rouen/chanteurs/index. html "/> 
<ResourceRef xl :href=" http: //www. chauveau . com/genealogie/ jean. html "/> 
</sub j ectldenti ty> 
<baseName> 

<baseNameString>Dean Chauveau</baseNameString> 
</baseName> 
<occurrence> 
<instanceOf> 

<topicRef xl : href="#photo"/> 
</instanceOf> 

<ResourceRef xl :href="DC1921.gif" /> 
</occurrence> 
</topic> 

La difference semantique entre les elements sub j ectldenti ty et occurrence appa- 
rait clairement : le premier renvoie a des ressources qui decrivent le sujet, tandis que 
le second indique les endroits physiques ou le sujet apparait. 
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Carte de topiques deduites du balisage 

Une carte de topiques peut etre produite a partir d'ensembles de donnees structures 
comme en presentent les documents XML et pour lesquels les relations entre les 
topiques sont formellement ou implicitement decrites. 

II est interessant d'avoir a l'esprit qu'une carte de topiques existe implicitement dans 
tout document XML contenant un balisage semantique de l'information. Pour mon- 
trer cela, nous allons utiliser l'exemple suivant : 

<auteur> 
<prenom>Jean</prenom> 
<nom>Noel </nom> 

<fonction>Di recteur</fonction> 
<adresse> 

<soci ete>CAEDIS</soci ete> 

<vi 1 1 e>Bon s-Gui 1 1 aume</vi 11 e> 

<pays>France</pays> 

<tel>+33 235604289</tel> 

<fax>+33 235604290</fax> 

<emai 1 > j noel @caedi s . com</emai 1 > 

<si tewetowww . caedi s . com</si teweb> 
</adresse> 
</auteur> 

Ce balisage identifie : 

• Des classes d'information telles que auteur, societe, ville, pays... A chaque 
element peut correspondre un topique. 

• Des associations: auteur/societe, societe/ville, vi lie/pays, auteur/ 
telephone, etc. 

• Des occurrences : les valeurs contenues dans le balisage. Chaque donnee peut etre 
l'occurrence du topique correspondant a l'element encadrant la donnee. 

La carte de topiques ainsi deduite de ce fragment XML devra toutefois etre terminee 
manuellement au cas ou les topiques devraient etre hierarchises. 

Lors de la recuperation automatique des donnees a partir d'un document XML, l'une 
des taches consiste a lisser le resultat obtenu, notamment les occurrences. Par 
exemple, deux numeros de telephone identiques peuvent ne pas avoir ete ecrits tout a 
fait de la meme maniere, idem pour les noms de ville (par exemple, Bois-Guillaume 
versus Bois Guillaume sans trait d'union). II se peut qu'un seul document XML (et 
c'est meme certain) ne represente pas a lui tout seul tous les cas que Ton voudrait 
modeliser avec une carte de topiques. 
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Ce petit exemple montre deja l'etendue des possibilites et les ouvertures offertes par 
l'approche Topics Map : 

• Tous les elements ne sont pas candidats a devenir des topiques ou des associa- 
tions. Par exemple, il serait idiot de produire des associations tel/vi 1 1 e ou mai 1/ 
tel . La classification des topiques finalement definie representera une vision dif- 
ferente, souvent plus large, de celle fournie initialement par le document XML 
ayant servi a la construire. 

• Des documents XML ayant des vocabulaires differents pourront facilement etre 
mis en correspondance avec une Topics Map existante. II suffira pour cela d'ecrire 
les regies de correspondance des topiques. 

• Inversement, des catalogues d'informations non balisees pourront etre confronted 
a notre Topics Map. Par exemple, si le nom Dean Noel est repere dans un fichier 
informatique, on pourra esperer trouver rapidement ce que la carte de topiques 
contient, de maniere structuree, a son sujet (sans jeu de mot !). 



Questions relatives a la gestion des liens 

Dans cette section, nous allons etudier les consequences des documents massivement 
hyperlies en termes de gestion des contenus qui touchent les mecanismes : 

• de gestion des revisions, 

• de gestion des liens, 

• de gestion des documents. 

La gestion des revisions pose un probleme tout a fait particulier dans le cas des docu- 
ments hyperlies et nous allons l'expliquer. Notamment, nous allons montrer com- 
ment l'augmentation du nombre de liens peut emprisonner peu a peu un systeme de 
gestion de documents. 

Le probleme de la gestion des liens apparait des que les documents doivent etre geres 
en configuration. 

Enfin, la gestion du document devient problematique des qu'il n'est plus qu'un 
receptacle de donnees stockees a l'exterieur. Nous allons expliquer ce qui se passe 
dans ce cas. 

Liens et gestion des revisions 

Dans la plupart des environnements professionnels, les imperatifs de tracabilite de 
l'information et de securite (par l'identification de l'information) imposent des con- 
traintes fortes sur les documents electroniques. 
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Dans le monde du Web et des pages HTML, il existe encore peu de contraintes (et 
de possibilites) d'affichage des revisions, mais dans les versions papier et electroni- 
ques des documents sensibles, ces contraintes sont particulierement pregnantes et 
difficiles a respecter. Une seule donnee modifiee dans un systeme de gestion et c'est 
potentiellement une cascade de mises a jour qu'il faut effectuer : republication des 
documents avec mise en valeur de la donnee modifiee, reperage exact de la page 
modifiee, production d'une liste effective des pages, declenchement d'une demande de 
mise a jour de tel ou tel autre document, etc. 

La mise a jour d'un seul document peut avoir des repercussions sur les processus et 
entrainer la modification d'un certain nombre d'autres documents, en particulier 
ceux qui lui sont lies. C'est ainsi qu'il existe, comme nous allons le voir, un risque non 
negligeable de paralysie d'un referentiel documentaire. 

Le risque : la paralysie du systeme 

Tout le probleme part de ce que les liens sont generalement definis au moyen d'iden- 
tifiants uniques : un element XML est pourvu d'un identifiant que Ton reference 
ailleurs, complete du chemin d'acces en dur au fichier qui le contient. Le probleme se 
pose de la meme facon, que les identifiants soient des ID/IDREF ou des URL. 

Or, la contrainte de tracabilite cree la situation cornelienne suivante : pour conserver 
l'ancienne version d'une donnee XML, il n'y a que deux possibilites : la duplication 
de la totalite du document XML contenant la donnee modifiee ou la duplication du 
seul element XML la contenant. Dans le premier cas, l'identifiant originel de l'ele- 
ment peut etre conserve mais le nom du document doit fatalement etre change. Dans 
le second cas, l'identifiant unique doit etre modifie. Dans un cas comme dans l'autre, 
on rencontre de facto un probleme avec le document qui contenait des liens vers cette 
donnee modifiee : dans le premier cas, il faut potentiellement changer tous les para- 
graphes contenant un quelconque lien vers le document revise, et dans le second il 
faut seulement modifier les paragraphes contenant un lien vers la seule information 
modifiee. Toujours est-il que ces documents sont eux aussi modifies, et, par souci de 
tracabilite, doivent encore etre modifies, et ainsi de suite ! 

Par effet de propagation, on aura compris que c'est potentiellement la totalite des 
documents qui doit etre dupliquee en consequence d'une unique modification de 
valeur dans un paragraphe d'un des documents de la base. 

La solution 

Pour lutter contre ce risque, la solution consiste a : 

• ne pas chercher a multiplier les petites entites, 

• mettre en place une politique d'adressage logique des ressources, 
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• etudier l'ensemble des mecanismes qui permettront de generer automatiquement le 
plus grand nombre possible de liens au moment de la publication de l'information. 

Pour les cas les plus compliques, le lecteur se reportera utilement au chapitre 13 trai- 
tant de la gestion des revisions, ou est detaille un modele mettant en oeuvre les URN 
(Uniform Resource Names). 

Liens et gestion de configuration 

La gestion de configuration consiste a gerer differentes versions d'un meme materiel 
ou logiciel. La consequence directe sur la documentation est quelle sera composee de 
parties communes, combinees avec des parties specifiques. 

Limpact sur les liens est immediat. Quand les parties specifiques viennent remplacer 
des parties communes, il faut garantir que tous les liens restent coherents. 

Pour illustrer notre propos, nous allons reutiliser l'exemple fourni en debut de cha- 
pitre et illustre a la figure 12-3. 

Rappelons au prealable un point evoque a la section precedente : quand un fichier 
contient des donnees XML, il est possible de definir localement une variante en uti- 
lisant un balisage special, mais quand un fichier renferme des donnees non-XML, le 
seul moyen de creer une variante est d'en faire une copie. La gestion de configuration 
pose des lors, au regard des liens, un probleme serieux. 

Imaginons qu'un meme appareil vendu en France, en Suisse et au Canada n'ait pas 
exactement la meme configuration dans chacun de ces pays. A langue et structure 
logique egale, la structure d'assemblage de la documentation fera appel a des res- 
sources physiques differentes. 

Supposons par exemple que le module modi contienne une illustration et qu'il existe 
deux versions du module mod2 : l'une pour la France, 1' autre pour la Suisse 
(mod2-F.xml et mod2-S.xml). Lillustration existe egalement en deux versions, l'une 
pour la France, 1' autre pour la Suisse (i 11usl-F.gif et illusl-S.gif). 

Le module modi, xml est commun a toutes les versions : 

<module> 
<avcorps> 
<"linkld id="Ll"> 

<target id="e07652" type="element">i 5</target> 
</linkId> 
<"linkld id="Fl"> 

<target type="enti ty">l -i 1 1 usl</target> 
</linkId> 
</avcorps> 
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<body> 

<p id="pl">Ce paragraphe contient un lien vers un <link ref="Ll"> 

element</link> de document 2 et une <link ref="Fl">illustration 

</link>.</p> 

</body> 

</module> 

Le module mod2-F.xml est specifique a la France : 

<module> 
<avcorps> 
<linkld id="Ll"> 

<target id="e07651" type="element">pl</target> 
</linkId> 
</avcorps> 
<body> 

<p id="i 5">VERSI0N francaise. De ce paragraphe part un lien vers les 
specifications <link ref="Ll">de lien e07651</link> local a ce document 
2</p> 
</body> 
</module> 

Le module mod2-S.xml est specifique a la Suisse : 

<module> 
<avcorps> 
<linkld id="Ll"> 

<target id="e07651" type="element">pl</target> 
</linkId> 
</avcorps> 
<body> 

<p id="i 5">VERSI0N Suisse. De ce paragraphe part un lien vers les 
specifications <link ref="Ll">de lien e07651</link> local a ce document 
2</p> 
</body> 
</module> 

Des lors, on peut concevoir des documents XML faisant a la fois office de structure 
d'assemblage des publications et de base de transposition. 

Ce qui donne pour la version francaise : 

<pub version="France"> 

<ressourceId id="L07651" type="entity">e07651</ressourceld> 
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<ressourceId id="L07652" type="entity">e07652</ressourceld> 
<ressourceId id="l -"il"lusl" type="entity">Illusl-F.gif</ressourceId> 

<section title="PCD" id=" i07650"> 
<ressource title="FS Export" url="f"Me://c:/doc/modl.xm"l " 
ressourceId="L07651"/> 
</section> 

<section title="sub-PCD" id=" i07652"> 
<ressource title="FS Export" url="f"ile://c:/doc/mod2-F.xml " 

ressourceId="L07652"/> 
</section> 
</put» 

et pour la version Suisse : 

<pub version="Suisse"> 

<ressourceId id="L07651" type="entity">e07651</ressourceld> 
<ressourceId id="L07652" type="entity">e07652</ressourceld> 
<ressourceId id="~l-i"l"lusl" type="entity">Illusl-S.gif</ressourceId> 
<section title="PCD" id=" i07650"> 
<ressource title="FS Export" url=" file://c:/doc/modl.xml " 
ressourceId="L07651"/> 
</section> 

<section title="sub-PCD" id=" i07652"> 
<ressource title="FS Export" url=" file://c:/doc/mod2-S.xml " 
ressourceId="L07652"/> 
</section> 
</pub> 

Avec un tel modele, le passage de la version francaise a la version Suisse ne necessite 
pas davantage que le changement de deux informations, ce qui est un gage important 
de coherence du contenu final. 

Ce type de modele permet surtout d'aller encore plus loin et de produire automati- 
quement, a partir de regies generiques de gestion de configuration, les differentes 
versions de la structure d'assemblage. 

Si le modele et les eventuelles tables relationnelles sont relativement simples a mettre 
au point, il n'en est pas de meme des interfaces utilisateurs de saisie : la manipulation 
de liens abstraits est quelque chose de difficile a apprehender pour l'esprit humain, et 
l'ergonomie des interfaces homme-machine est, dans le cas d'une saisie manuelle, 
difficile a obtenir de maniere generique ; en revanche, il est possible de le faire pour 
des applications metier specialisees. 
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Mecanismes permettant de controler les liens partir d'un schema 

Avant d'entrer dans le probleme du controle de la pose des liens, rappelons les diffe- 
rents types de liens disponibles avec XML : 

• Les liens hierarchiques explicites issus de la nature meme de XML. II s'agit des 
relations de type parent-enfant et fratrie induites par la nature imbriquee du bali- 
sage XML. 

• Les liens hierarchiques implicites, rendus explicites par des expressions XPath 
(une table des matieres par exemple). 

• Les liens point a point exprimes par des couples ID/IDREF. 

• Les liens identitaires de type Key/Keyref. 

• Les liens autres exprimes par le modele XLink. 

Tous ces liens ne dependent pas du schema XML. Par exemple, les liens implicites 
crees par des expressions XPath (ou XQuery) echappent totalement au controle du 
schema. Ces liens apparaissent posterieurement a la creation du document XML et 
sont principalement le fruit des applications qui vont exploiter les donnees XML. 

En revanche, les liens identitaires de type Key/Keyref dependent exclusivement du 
schema : seule sa connaissance permet de retrouver ces liens (le mecanisme des cles et 
references de cles permet, via un schema, de garantir qu'une donnee est egale a une 
autre - ce qui lie implicitement les deux donnees entre elles). 

C'est en evaluant les possibilites offertes par un schema XML que Ton se fait une 
idee du controle qu'il exerce sur les liens. Par exemple, si un schema XML n'autorise 
que le type ID/IDREF, on dira qu'il est ferme car il oblige les sources et les cibles des 
liens a etre physiquement dans le meme document. A contrario, un schema XML 
mettant en ceuvre le type xs:anyURI est ouvert car il permet d'utiliser n'importe 
quelle cible. Entre Fun et 1' autre de ces deux extremes, il y a le mecanisme des 
facettes de XML Schema pour controler la forme des URI utilisees dans un docu- 
ment XML. Ainsi, il est possible de controler que le debut d'une URI correspond a 
une liste de valeurs autorisees. 

Le schema XML suivant permet de controler que les URI utilisees dans 1' element 
uri respectent une forme lexicale commencant par http://www.xmldev.com/. Le 
type anyURI (repere ©) y est restreint par utilisation de la facette xs:pattern speci- 
fiant une forme lexicale au moyen d'une expression reguliere (repere O). 

<xs : schema xml ns : xs="http : //www. w3 . org/2001/XMLSchema"> 
<xs:simpleType name="uriType"> 
<xs: restriction base="xs:anyURI"> <- 
<xs: pattern value="http: //www. xml dev.com/. *"/> <- O 

</xs : restrict! on> 
</xs : si mpl eType> 
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<xs:element name="uris"> 
<xs : compl exType> 
<xs:sequence> 
<xs:element name="uri" maxOccurs="unbounded"> 
<xs:simpleType> 

<xs:list itemType="uriType"/> 
</xs : si mpl eType> 
</xs:element> 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 
</xs: schema> 

Le premier fragment XML suivant est valide par rapport a ce schema, tandis que le 
second ne Test pas (les erreurs sont mises en gras) : 

<?xml version="1.0" encoding="UTF-8"?> 

<un's xmlns :xsi=" http://www.w3 . org/2001/XMLSchema- instance" 
xsi : noNamespaceSchemaLocati on="7-f acetteURI . xsd"> 
<u ri >http : //www . xml dev . com/xml data . xml </u ri > 
<u ri >http : //www . xml dev . com/model e/exempl e/i ndex . html </u ri > 

</uris> 

<?xml version="1.0" encoding="UTF-8"?> 

<uris xmlns : xsi =" http://www.w3 . org/2001/XMLSchema- instance" 
xsi : noNamespaceSchemaLocati on="7-f acetteURI . xsd"> 
<uri>http: //www . xml dev . net . org/xml data . xml </u ri > 
<u ri >http : //www . xml be . com/model e/exempl e/i ndex . html </u ri > 

</uris> 

On peut aussi controler la forme lexicale des liens en utilisant une bibliotheque de 
valeurs referencees a l'aide des mecanismes key/key ref de XML Schema. 

Le schema suivant definit une bibliotheque d'URI tous differents (ce sont des cles de 
type xs : key) : 

<xs : schema xml ns : xs="http : //www. w3 . org/2001/XMLSchema"> 
<xs: element name="uris"> 
<xs : compl exType> 
<xs:sequence> 
<xs:element name="uri" maxOccurs="unbounded"> 
<xs:simpleType> 

<xs : 1 i st i temType="xs : anyURI"/> 
</xs : si mpl eType> 
</xs :element> 
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</xs:sequence> 
</xs : compl exType> 

<xs:key name="uriDansBibliotheque"> 
<xs: selector xpath="uri"/> 
<xs: field xpath="."/> 
</xs : key> 
</xs:element> 
</xs:schema> 

Ce schema valide par exemple la bibliotheque d'URI suivante : 

<?xml version="1.0" encoding="UTF-8"?> 

<uris> 
<u ri >http : //www . xml dev . com/xml data . xml </u ri > 
<uri>http : //www. xml dev . com/model e/exempl e/i ndex . html </uri> 

</ur"is> 

On peut des lors ecrire un schema dans lequel certains elements se verront imposer 
un contenu, lequel devra dans le cas present etre l'un des URI de la bibliotheque. 

<?xml version="1.0" encoding="UTF-8"?> 
<xs : schema xml ns : xs="http : //www. w3 . org/2001/XMLSchema"> 
<xs: include schemaLocation="7-bibUris.xsd"/> 
<xs : el ement name="col 1 aborateurs"> 
<xs : compl exType> 
<xs:sequence> 
<xs:element ref="uris"/> 

<xs:element name="collaborateur" maxOccurs="unbounded"> 
<xs : compl exType> 
<xs:sequence> 

<xs: el ement name="fiche" type="xs:anyURI"/> 
</xs: sequence> 
</xs : compl exType> 
</xs:element> 
</xs:sequence> 
</xs : compl exType> 

<xs: key name="un'DeLaBibliotheque"> 
<xs: selector xpath="uris/uri "/> 
<xs: field xpath=" . "/> 
</xs : key> 

<xs:keyref name="ficheCollaborateur" refer="uriDeLaBibliotheque"> 
<xs : sel ector xpath="col 1 aborateur/f iche"/> 
<xs: field xpath="."/> 
</xs : keyref > 
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</xs:element> 
</xs: schema> 

Et voici une instance valide de ce schema : 

<conaborateurs> 

<! — 

<xi:include href="7-bibUris .xml " parse="text" encoding="CDATA" 
xml ns : xi ="http : //www . w3 . org/2001/XIncl ude"/> 

--> 

<uris> 
<u ri >http : //www . xml dev . com/xml data . xml </u ri > 
<u ri >http : //www . xml dev . com/model e/exempl e/i ndex . html </u ri > 

</uris> 

<collaborateur> 

<fi che>http : //www . xml dev . com/xml data . xml </fi che> 
</collaborateur> 
</col 1 aborateu rs> 



Remarque Bibliotheque d'URI 

Dans le dernier document XML, nous avons insere en dur la bibliotheque d'URI, mais avons parallele- 
ment mentionne I'inclusion qu'il faudrait declarer avec xi : i ncl ude de la recommandation Xlnclude 
du W3C pour eviter de devoir dupliquer la bibliotheque d'URI. 



VOCABULAIRE Integrite referentielle 

L'integrite referentielle d'un lien est sa coherence : il s'agit non seulement de controler que la cible existe 
mais encore qu'elle est juste. 



En conclusion, XML Schema ne permet pas a lui tout seul de bien controler l'inte- 
grite referentielle des liens. On ne peut y proceder qu'au moyen de programmes de 
calcul capables de controler les liens au regard de regies metier. 

Au mieux, un schema controlera si la pose d'un lien est autorisee et si sa forme lexi- 
cale est correcte. 
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En resume 



Dans ce chapitre, nous avons fait un long periple au travers de differents modeles de 
liens et langages de liaison, depuis le cas des ID/IDREF, considere comme le plus 
simple, a celui des cartes de topiques. Cependant, la derniere partie du chapitre a 
montre que des modeles particulierement sophistiques pouvaient etre realises en 
s'appuyant sur le seul mecanisme des ID/IDREF (complete il est vrai d'un modele 
relationnel) ! 

Est-ce a dire que le sujet des liens ne fait pas partie des plus simples ? La reponse est 
oui. Le sujet est complexe et complexes sont ses representations. 

Laffirmation « le volume cree le probleme » est ici verifiee. Creer un lien dans un 
document n'est pas un probleme, mais en creer des centaines de milliers dans des 
milliers de documents est un probleme qui necessite une modelisation prealable. 
Nous avons offert dans ce chapitre une palette de solutions. 

Si nous avons presente en partie les vocabulaires normalises des modeles Xlink et 
XTM, nous avons aussi insiste sur les problemes de gestion que posent les liens. 
Reviser un document ou un ensemble d'informations, le transporter, et enfin en gerer 
l'applicabilite par rapport a une configuration de systeme est un probleme complexe 
des lors que des liens entrent en ligne de compte. 

En particulier, la gestion combinee des liens, des revisions et des processus est une 
question delicate car, quand bien meme on saurait resoudre le probleme sur le plan 
technique, il n'en resterait pas moins qu'il faut offrir aux utilisateurs des interfaces con- 
viviales de controle, d'acces et de saisie des liens ; ce n'est pas impossible, mais couteux. 

Nous allons etudier dans le chapitre suivant un autre probleme potentiellement 
delicat, celui de la gestion des revisions. 
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Modeles pour la gestion 
des revisions et des versions 



Void une demarche, agrementee d'exemples, qui permet de trouver le modele appro- 
prie a la gestion de differentes revisions et versions de documents XML. 

La gestion des revisions et des versions doit toujours, avec XML, etre etudiee sous les 
deux facettes qui forment l'ossature de ce chapitre : 

• celle du balisage a appliquer a l'interieur du document XML, 

• celle de la gestion de l'enveloppe, a savoir le document XML en tant que fichier. 

Sur le plan de la modelisation XML, gerer des revisions ou des versions revient au 
meme. Dans les deux cas, le probleme est celui de Tidentification des objets et de la 
commodite avec laquelle on peut passer de l'un a l'autre : d'une revision a une autre, 
d'une version a une autre. 

Nous verrons dans ce chapitre des exemples et des modeles portant sur les deux cas 
de figure. 
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Gestion des revisions a I'interieur d'un document XML 



Introduction 

La gestion des modifications apportees a un document XML est a la fois chose 
simple et compliquee : 

• Simple, parce que la nature meme du balisage XML permet d'envisager toutes 
sortes de marquage des revisions. Nous en rappelons l'essentiel dans cette intro- 
duction. 

• Compliquee, car ce balisage souleve des problemes specifiques que nous detaille- 
rons dans une section qui leur est dediee. 

Nous verrons que, sous certaines conditions, il est possible d'identifier les differences 
entre documents XML apres y avoir porte des modifications. 

Des que Ton aborde l'etude du marquage des revisions, une premiere question vient a 
l'esprit : « Que doit-on indiquer au juste ? » 

Effectivement, s'il semble evident de baliser tel ou tel paragraphe modifie et la ver- 
sion du document correspondante, il est ensuite beaucoup plus delicat de decider du 
type d'information de revision qu'il est souhaitable de conserver. Void des exemples 
des informations susceptibles d'etre conservees entre deux revisions : 

• Qui a fait la modification ? 

• Quelle est la nature de la modification ? 

• Quelle est la raison de la modification ? 

• Qy'est-ce qui, tees exactement, a ete modifie ? 

• Qui a valide la modification ? 

• Quelle est la date de la modification ? 
II y en a bien d'autres encore. 



Les possibility de balisage des revisions 



Utilisation d'attributs 



II est possible de marquer les revisions en utilisant un ensemble d'attributs autorises 
par la DTD ou le schema sur tout ou partie des elements XML. 

Les attributs revnum, revdate, revaut et revtype, par exemple, enregistrent respective- 
ment le numero de version du document, la date de la revision, son auteur et son type. 
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Le balisage ci-apres indique que le paragraphe a ete modifie dans la version 2.1 du 
document, le 14 aout 2004 a 9 h 30 par Didier : 

<p revnum="2.1" revdate="2004-08-14T09: 30" revaut="Didier" 
revtype=" change "> 

Cette solution presente les avantages suivants : 

• La structure originelle du document n'est pas modifiee. Les attributs sont ajoutes 
a tout moment, sur n'importe quel element defini par une DTD ou schema 
XML. Avec XML Schema, les attributs de revision peuvent meme etre ajoutes 
aux types en les derivant par extension. 

• Les valeurs utilisees seront partiellement controlees en utilisant des listes derou- 
lantes de valeurs predefinies ou des derives de types simples en ce qui concerne 
XML Schema. 

Cependant, elle a les inconvenients suivants : 

• Pas de possibilite de borner precisement la portion modifiee du texte. Les bornes 
sont celles des elements de la DTD ou du schema qui, en general, hont pas ete 
concus dans une optique de gestion des revisions. 

• Pas de possibilite de cumuler les revisions puisqu'on ne peut mettre par element 
qu'un seul attribut de meme nom. Avec cette technique, la recopie des fichiers 
entre deux revisions est obligatoire. 

Utilisation de balises fixes 

Nous qualifions ici de fixes les balises dont l'emplacement est prevu par la DTD ou 
le schema XML, par opposition aux balises flottantes, specificite de SGML qui sera 
presentee dans la prochaine section. 

Les balises fixes peuvent etre, au choix : 

• trois elements (par exemple new, del et chg) pour indiquer une nouveaute, une 
suppression ou un changement ; 

• un seul element (par exemple rev) accompagne d'un attribut specifiant la nature 
de la modification (par exemple change="new" , change="del ", change="mod"). 

La balise de fin delimite la zone revisee. 

La balise de debut peut porter d'autres attributs pour fournir des indications supple- 
mentaires sur la revision. 

Cette solution a l'avantage de rendre possible le cumul des revisions. 
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Toutefois, elk a les inconvenients suivants : 

• II est difficile d'introduire ces elements dans la structure. S'il est simple de les 
introduire a l'interieur des elements textuels, il n'est pas aise de le faire dans le cas 
de structures plus complexes comme des tableaux, chapitres, sections... 

• En dehors des contenus textuels, cette technique apporte plus d'inconvenients que 
d'avantages par rapport a la technique des attributs vue a la section precedente. 

Le balisage suivant a ete produit par Microsoft Word™ 2000 en mode revision. 
Nous l'avons simplifie et mis en gras pour le rendre explicite : 

<pxdel cite="Didier" datetime="2004-08-14T09:30">toto</del> 

<ins cite="Didier" datetime="2004-08-14T09:30">j jt</ins> 

</p> 

<table> 

<tr sty1e='mso-table-inserted:Didier 20040814T0933'> 

<td> 

<pxins cite="Didier" datetime="2004-08-14T09:33">a</ins></p> 

</td> 

On observe que Microsoft Word™ utilise la technique du balisage quand il s'agit de 
marquer les revisions du contenu textuel, mais celle des attributs pour marquer la 
revision des structures complexes, ici un tableau. 

II est a noter que Word utilise dans le cas de 1' element tr un attribut (style) suf- 
frxant un attribut standard et non des attributs specifiquement dedies a la gestion des 
revisions. On pourra noter egalement que l'indication d'insertion du tableau 
(mso-table-inserted) a ete enregistree sur la premiere rangee du tableau et non sur 
1' element tabl e lui-meme. Comme nous l'avons dit, la technique qui consiste a uti- 
liser les attributs ne permet pas le cumul des revisions. Aussi, comme vous l'aurez 
peut-etre deja remarque, Word informe les utilisateurs que les modifications sur les 
tableaux (notamment les suppressions) ne peuvent pas etre gerees en revision. 

On se doute que ce type de balisage est quasi impossible a poser a la main. Sa gene- 
ration doit etre assuree par l'editeur XML utilise. 

Utilisation de balises flottantes 

Lutilisation de balises flottantes est une specificite de SGML. Pour fonctionner, 
cette technique s'appuie sur les grammaires de Relax NG et le mecanisme des excep- 
tions qui n'existe ni dans les DTD de XML 1.0 ni dans les schemas de 
XML Schema. 

Le mecanisme des exceptions consiste a autoriser ou interdire l'usage d'elements spe- 
cifies a partir d'un certain element de l'arbre. Ainsi, il est possible d'indiquer dans une 
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DTD qu'une balise, revst par exemple, est autorisee n'importe ou a partir de l'ele- 
ment racine. II suffit pour cela d'ecrire +( revst) comme dans l'exemple ci-apres : 

I <! ELEMENT root - - (title , para+) +(revst)> 

Une revision chevauche souvent plusieurs elements. Aussi, pour satisfaire a l'idee 
qu'une revision commence dans un element et se termine dans un autre, deux balises 
independantes et mises en exception sont autorisees : 

• une balise de debut de revision, revst par exemple ; 

• une balise de fin de revision, revend par exemple. 
Dans la DTD, cela se traduit par la definition suivante : 

I <! ELEMENT root - - (title, para+) +(revst | revend)> 

Ainsi, il est possible de baliser une modification qui figurerait a cheval sur deux 
paragraphes : 

<PARA>aaaaaaaa<REVST/>fffffffffffffff</PARA> 
<PARA>ffffffffff<REVEND/>aaaaaaaaa</PARA> 

Malheureusement, il est tout autant valide d'ecrire : 

<PARA>aaaaaaaa<REVEND/>fffffffffffffff</PARA> 
<PARA>ffffffffff<REVST/>aaaaaaaaa</PARA> 

En effet, le mecanisme des exceptions ne controle pas l'ordre des elements ainsi utilises. 
Cette solution presente les avantages suivants : 

• La facilite de mise en ceuvre : les marques de revisions peuvent chevaucher 
n'importe quel element de structure. 

• Les marques de revision peuvent etre porteuses de leurs propres attributs de qua- 
lification. La marque de fin peut etre porteuse d'attributs tout autant que la mar- 
que de debut. 

• Permet de cumuler les revisions. 

• Tres facile a introduire dans n'importe quelle DTD SGML. 
Cependant, elle a les inconvenients suivants : 

• Elle ne permet pas de garantir la parite des balises de debut et de fin. II s'agit de 
deux elements vides, independants Fun de l'autre. Nous avons vu que de grossie- 
res erreurs de balisage pouvaient etre commises sans que le parseur s'en apercoive. 



_ Modeles de reference 

Deuxieme partie 

• Elle donne quelquefois des informations contradictoires avec la structure. Dans 
l'exemple suivant, l'ordre de destruction porte sur l'element de debut de paragra- 
phe sans recouvrir la balise fermante. Le fragment que nous donnons en exemple 
est pourtant structurellement juste : aucun parseur ne verra l'aberration de la 
situation jusqu'au moment ou la portion detruite sera physiquement supprimee 
du document XML. A ce moment la seulement, apparaitra un serieux probleme 
de structure. 

<DOCTYPE root [ 

<! ELEMENT root - - (para+) +(revst | revend)> 

<! ELEMENT para - (#PCDATA)> 

<! ELEMENT (revst | revend) - EMPTY> 

<!ATTLIST(revst, revend) revtype (del | new| chg) 'ins' 

revindicator id #REQUIRED> 

> 

<root> 

<REVST revtype="del " revindicator="a412"/><PARA>aaaaaaaa<REVEND 

revtype="del " revindicator="a412"/>f ff fff fff fff fff</PARA> 
</root> 

Ces quelques exemples disent assez a quelle difficulte on s'expose avec ce type de 
balisage que nous devons etudier en detail. 

Les difficultes du balisage des revisions 

Balisage contraint par le balisage principal 

Nous qualifions ici de balisage principal celui qui structure veritablement le docu- 
ment XML ; par opposition au balisage qui pourrait etre appele secondaire, car non 
determinant pour la structure du document (par exemple le balisage dedie aux meta- 
donnees, aux mises en valeur, aux revisions le cas echeant...). 

Ce qui est interessant, c'est qu'en faisant porter les informations de revision par le 
balisage principal, on met l'accent sur les modifications apportees a la structure prin- 
cipal du document. 

Certes, la precision en souffre puisque, comme nous l'avons vu plus haut, il est 
impossible d'encadrer le mot -voire le caractere - modifie. 

Nous allons helas soulever ici un probleme profondement antinomique avec le con- 
cept meme de balisage principal. Ce probleme survient a partir du moment ou Ton 
souhaite garder l'historique des revisions. 
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Envisageons la DTD XML suivante, somme toute tees banale : 

<DOCTYPE root [ 

<! ELEMENT root (section+)> 

<! ELEMENT section (titre,para+)> 

<! ELEMENT titre (#PCDATA)> 

<! ELEMENT para (#PCDATA)> 

<!ATTLIST titre revnum CDATA #REQUIRED 

revtype (new| del | ch) 'ins'> 

<!ATTLIST para revnum CDATA #REQUIRED 

revtype (new| del | ch) 'ins'> 

]> 

Elle valide le document suivant : 

<root> 
<section> 
<titre revnum="1.0" revtype="new">Ceci est le titre originel</titre> 
<para>aaaaaaaa</para> 
</section> 
</root> 

Et, si le titre est modifie et que Ton souhaite garder l'historique, cela devrait dormer 
en version 1 : 

<root> 
<section> 
<titre revnum="1.0" revtype="new">Ceci est le titre originel</titre> 
<titre revnum="2.0" revtype="chg">Ceci est le titre modifie</titre> 
<para>aaaaaaaa</para> 
</section> 
</root> 

Or, la DTD interdit de dupliquer la balise titre. Cette version du document nest 
done pas valide. 

En extrapolant ce probleme, on s'apercoit que, pour garder l'historique des revisions, 
il devrait etre possible de repeter tous les elements de la DTD. Ce qui est, bien evi- 
demment, totalement antinomique avec le concept de balisage principal. Voila pour- 
quoi la gestion des revisions devient rapidement incompatible avec la simple pose 
d'attributs sur le balisage principal. 

Toutefois, lorsque cette technique est retenue, la seule solution pour garder l'histo- 
rique consiste a dupliquer le document XML a chaque nouvelle revision. 
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Revision des attributs 

Les attributs des documents XML peuvent contenir des informations importantes. 
La gestion des revisions peut egalement s'appliquer aux attributs. 

Or, il nest pas possible de conserver les valeurs successives d'un attribut. Le seul 
moyen d'y pourvoir, c'est de dupliquer 1' element auquel il appartient. 

Quand la gestion des revisions s'impose pour les attributs, il convient de reflechir a la 
possibilite de remplacer les attributs concernes par des elements simples. 

Les liens 

Comme nous l'avons exprime au chapitre precedent, la gestion des revisions peut 
avoir des consequences non negligeables quand des liens sont en jeu. 

Lunivers des documents XML est compose de fichiers contenant des donnees bali- 
sees et des entites graphiques, le plus souvent de format binaire. 

En ce qui concerne les entites graphiques, il est aise de comprendre que toute gestion 
des revisions implique de proceder a une duplication du fichier graphique avant de le 
modifier. 

De leur cote, les documents XML doivent egalement etre dupliques car il advient 
toujours un moment ou il n'est plus possible de cumuler les modifications par un 
simple balisage interne (voir section precedente). Eux aussi doivent etre dupliques. 

Dans les deux cas, le probleme qui se pose est celui d'une duplication des fichiers, et 
done des liens qui doivent s' adapter a leur nouvelle cible. 

Avec les documents XML, le probleme de la gestion des revisions prend une nou- 
velle dimension, les liens et la modularisation etant desormais faciles a realiser. 

Nous verrons ci-apres le cas concret de la norme S1000D : cette norme generalise 
l'usage des noms uniformes de ressources (URN, pour Uniform Ressource Name) et de 
serveurs d'URN comme reponse a ce probleme delicat. 

Difficultes pour les auteurs 

On s'en sera doute au vu des balisages presentes dans la premiere section de ce cha- 
pitre, placer les informations de revision n'est pas chose simple pour les auteurs. 

Tout d'abord, ces derniers doivent initialiser les informations de revision puis, a 
chaque modification, ne pas oublier de renseigner les champs de gestion correspon- 
dants. C'est evidemment une tache trop complexe, risquant d'entrainer de nom- 
breuses erreurs. 

Si l'editeur XML utilise n'est pas capable de poser automatiquement les marques de 
revision, il convient de developper des programmes de comparaison. Ainsi, les 
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auteurs peuvent librement modifier un document XML qui sera ensuite compare a sa 
version precedente par un programme. 

Pour que la comparaison soit efficace et sans ambiguite, les differentes versions des 
documents XML doivent avoir la meme forme canonique. La definition d'une forme 
canonique fait l'objet de la recommandation du W3C « Canonical XML » du 
15 mars 2001. On designe par la le format d'enregistrement d'un document XML 
dans lequel toutes les valeurs par defaut des attributs ont ete mises, les blancs net- 
toyes, les entites appelees remplacees par le texte litteral qu'elles representent, les 
commentaires supprimes, les formes lexicales des types de base retablies dans leur 
forme officielle, etc. 

On le voit, la comparaison entre deux versions de documents XML, a posteriori de 
leur saisie, oblige a les canoniser, ce qui a pour effet d'en modifier quelque peu 
l'aspect. Cela n'est, la plupart du temps, qu'un epiphenomene. 



Un exemple de balisage 

Le modele que nous presentons ici est celui de FATA2100, un standard elabore pour 
la documentation technique des avions et de leurs equipements. Cette norme con- 
cerne aussi bien i'ensemble de l'avion que des petits equipements. 

Pour des raisons de securite, la gestion des revisions est un point important de la 
documentation des avions. La tracabilite des modifications doit etre assuree par plu- 
sieurs intervenants et plus d'une dizaine de types differents de documents, tous utili- 
sant les principes de gestion des revisions que nous presentons dans cette section. 

Structure racine 

La racine des documents techniques met immediatement l'accent sur la gestion des 
revisions. Dans la figure 13-1, ou nous avons pris pour exemple la DTD d'un manuel 
de maintenance, les elements increv et tr sont notes respectivement pour incre- 
mental revision et temporary revision. Ces deux elements et la sequence (title, 
mfmatr, chapter) s'excluent mutuellement. Cela signifie qu'une mise a jour ne con- 
cerne toujours qu'une partie du document originel (represente par la sequence title, 
mfmatr, chapter). Le principe retenu paries concepteurs de ce modele est celui d'une 
publication initiale, comportant ensuite des mises a jour incrementales. 

Deux types de mises a jour sont pris en compte : les modifications temporaires avec 
I'element tr, les mises a jours definitives avec I'element i ncrev. 
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Figure 13-1 
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L'element racine amm porte les quelques attributs de revision qui s'appliquent a 
l'ensemble du document: la date de premiere publication du manuel (oidate), la 
date de la derniere revision (revdate), son etat (chg). Envoici un exemple : 

<amm model="747" docnbr="747-21-2360" spl="81205" tsn="l" 
oidate="19940707" revdate="19950511" chg="R" lang="EN"> 

Les sections suivantes vont presenter les mecanismes internes a la structure mise en 
ceuvre pour la gestion des revisions. 



Structure de l'element mfmatr 

L'element mfmatr est l'avant-corps du manuel. II est constitue de plusieurs parties 
concernant pour la plupart la gestion des revisions et l'applicabilite du manuel. Dans 
cet avant-corps apparait la liste des revisions temporaires du document : trl i st (lit- 
teralement temporary revision list). Cette liste correspond aux modifications publiees 
au moyen de l'element tr explique plus loin. 



Figure 13-2 

Structure de ['element mfmatr 


I mfmatr Tjj 


pe 

-i transltr|+l 








i 


— |trlist r+l 
—lintro |+l 




| mfmatr EJD-(~™" )Eh 








— | efTxref l+l 
— {sblist r+l 
—I drindeK r+l 




L 


_l 



Modeles pour la gestion des revisions et des versions 

Chapitre 13 



Structure de l'element chapter 

Dans notre cas de figure, un chapitre est une entire repetable qui forme le corps du 
document technique. 

Deux elements concernent la gestion des revisions (chgdesc comme change descrip- 
tion et deleted, utilise au cas ou le chapitre serait entierement retire). 



Figure 13-3 

Structure de l'element chapter 
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Structure de l'element increv 

Le nom increv est l'abreviation de incremental revision, soit revision incremental. II 
s'agit d'un mecanisme de base isolant du reste du document les unites textuelles 
mises a jour. Treize noeuds, ou ancres - car on park a leur sujet de points d'ancrage 
des revisions -, sont autorises a prendre en charge cette operation. La figure 13-4 en 
montre la liste. 

La structure de l'element i ncrev possede une particularite : tous les elements sont au 
meme niveau hierarchique alors qu'ils correspondent a des niveaux de profondeur 
bien differents dans la structure originelle du document. L'element section figure en 
temps normal sous l'element chapter. Comme nous le disions en introduction de cet 
exemple, les concepteurs du modele ont prevu que les parties revisees pourraient faire 
l'objet d'une publication independamment du reste du document. 

Chaque ancre porte trois attributs de revision : 

• chg, comme change, peut prendre les valeurs N, D, R et U, qui signifient respective- 
ment New, Deleted, Revised et Unchanged. 

• key, comme cle, est un identifiant unique de type ID construit avec des regies tres 
precises permettant d'assurer la tracabilite des revisions. 

• revdate contient la date de la revision. 
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Figure 13-4 
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A l'interieur d'une ancre, les zones reellement modifiees sont encadrees par les 
balises de revision revst et revend. 

On remarquera que I'element trlist (liste des revisions temporaires) fait lui-meme 
l'objet d'un processus de revision incrementale puisqu'il est dans la liste des ancres : 
en effet, les blocs d'information dedies a la gestion des revisions sont eux-memes 
revises et sont done soumis aux memes regies de gestion des revisions que les autres 
elements textuels ou graphiques. 



Structure de I'element tr 

Les revisions temporaires correspondent au concept de page bis ou pages jaunes. Les 
pages sont inserees dans les publications en complement des anciennes pages. 

Le modele de contenu de I'element tr est, a peu de chose pres, le meme que celui de 
increv, et les memes ancres peuvent faire l'objet soit d'une revision temporaire, soit 
d'une revision incrementale, a l'exception de I'element i ntro et de la liste des revisions 
temporaires (trlist) qui ne fait pas elle-meme l'objet d'une mise a jour temporaire. 
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Figure 13-5 

Structure de I'element tr dedie 
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Ces structures montrent comment les etages superieurs du modele structurent la ges- 
tion des revisions. Nous allons desormais montrer ce qui se passe au niveau des para- 
graphes. 



Le bornage precis des revisions 

Les modifications sont marquees dans le corps du texte par deux elements flottants, 
denommes revst et revend. Concernant la technique que mettent en ceuvre ces ele- 
ments flottants, nous renvoyons au debut de ce chapitre. 

Ces elements n'ont comme duree de vie qu'une seule revision et sont reinitialises 
d'une revision a l'autre. lis ont comme objectif de marquer les differences d'une revi- 
sion n a n + 1. 

Ce qui etait indique comme revise (attribut chg="R") a une revision donnee 
deviendra U Unchanged a la revision suivante sauf si, bien sur, le contenu de l'ancre 
porteuse de cette information venait a changer a nouveau. 
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Ces regies vont etre illustrees par des cas typiques. Nous allons tout d'abord utiliser 
un fragment simple compose d'un chapitre, d'une section et d'une sous-section. Au 
depart, l'indicateur de revisions vaut U comme unchanged. 

<AMM> 

<CHAPTER CHG="U" > 

<TITLE>aaaaaaaaaaaaaaaaaaaaa</TITLE> 
<SECTION CHG="U"> 
<PARA>bbbbbbbbbbbbbbbbbbbbb</PARA> 
<SUBSEC CHG="U"> 

<PARA>ddddddddddddddddddddd</PARA> 
</SUBSEC> 
</SECTION> 
</CHAPTER> 
</AMM> 

Quand le premier paragraphe de la section est modifie, l'indicateur de revision de 
cette section, et uniquement de celle-la, passe a R comme revised. Le chapitre nest 
pas pour autant indique comme ayant ete revise ; la modification effectuee est cir- 
conscrite a la section, et le chapitre reste a l'etat U. 

<AMM> 

<CHAPTER CHC="U"> 

<TITLE>aaaaaaaaaaaaaaaaaaaaa</TITLE> 
<SECTION CHG="R" revdate="19941201" key="Ml"> 
<PARAxREVST>fffffffffffffffffffffffff<REVENDx/PARA> 
<SUBSEC CHG="U"> 

<PARA>dddddddddddddddddddd</PARA> 
</SUBSEC> 
</SECTION> 
</CHAPTER> 
</AMM> 

Lors de l'edition suivante, une information directement dependante du chapitre est 
modifiee, et le chapitre porte alors l'information de revision. L'indicateur de revision 
de la section precedemment modifiee revient a U puisque ces indicateurs sont reini- 
tialises a chaque nouvelle revision. 

<AMM> 

<CHAPTER CHG="R" revdate="19951201" key="M2"> 

<TITLExREVST>revi sed ti tl e<REVENDx/TITLE> 
<SECTION CHG="U"> 
<PARA>fffffffffffffffffffffffffff</PARA> 
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<SUBSEC CHG="U"> 

<PARA>ddddddddddddddddddddddddddd</PARA> 
</SUBSEC> 
</SECTION> 
</CHAPTER> 
</AMM> 



La destruction du contenu d'une ancre n'est possible que si la suppression de ce con- 
tenu est autorisee par le modele. Elle est alors remplacee par le seul element vide 
del eted et le fragment balise devient : 



<AMM> 

<CHAPTER CHC="U"> 

<TITLE>revised title</TITLE> 
<SECTION chg="D" revdate=" 19961201" key="M3"> 
<REVST> 
<DELETED> 
<REVEND> 
</SECTI0N> 
</CHAPTER> 
</AMM> 

Quand la destruction totale du contenu n'est pas possible ou quand la destruction ne 
concerne qu'une partie du texte, le balisage prend la forme suivante : 

<AMM> 

<CHAPTER CHC="U"> 

<TITLE>revised title</TITLE> 
<SECTI0N CHG="U"> 
<PARA>fffffffffffffffffffffffffff</PARA> 
<SUBSEC chg="R" revdate="19971201" key="M4"> 

<PARAxREVSTxREVENDx/PARA> 
</SUBSEC> 
</SECTI0N> 
</CHAPTER> 
</AMM> 

dans laquelle les balises <revst> et <revend> encadrent un contenu vide. 

Pour completer la gestion des revisions au niveau individuel, une liste recapitulative 
des nceuds modifies est elaboree. Cette liste des ancres effectives est aux revisions ce 
qu'une table des matieres est aux chapitres d'un ouvrage. Elle est introduite par l'ele- 
ment LEA (acronyme de Liste of Effective Anchors) et est composee d'elements dont 
le nom est ANCHOR. On y remarque les attributs key et treeloc : le premier contient 
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les identifiants des ancres, et le second la position nodale de chacune d'entre elles. II 
s'agit d'une double identification qui, de ce fait, est redondante. 

<LEA SPL="ATA/AIA" MODEL="A320" OIDATE="19920101" REVDATE=" 19920401" 

TSN="1" CUS="XXX" LANG="EN" D0CID="D0C"> 
<ANCH0R KEY="A112" REVDATE="19920101" CHG="U" TAGNAME="CHAPTER" 

TREEL0C="2"> 
<ANCH0R KEY="A113" REVDATE="19920401" CHG="R" TAGNAME=" SECTION" 

TREEL0C="3"> 
<ANCH0R KEY="A232" REVDATE="19920101" CHG="U" TAGNAME="CHAPTER" 

TREEL0C="14"> 
<ANCH0R KEY="A233" REVDATE="19920101" CHG="U" TAGNAME=" SECTION" 

TREEL0C="15"> 
<ANCH0R KEY="A235" REVDATE="19920101" CHG="U" TAGNAME=" SECTION" 

TREEL0C="21"> 
<ANCH0R KEY="A341" REVDATE="19920101" CHG="U" TAGNAME="CHAPTER" 

TREELOC="26"> 
<ANCH0R KEY="A342" REVDATE="19920101" CHG="U" TAGNAME=" SECTION" 

TREELOC="27"> 
<ANCH0R KEY="A343" REVDATE="19920101" CHG="U" TAGNAME=" SECTION" 

TREEL0C="31"> 
</LEA> 

La valeur de l'attribut treeloc est le numero d'ordre de l'ancre par rapport a la racine 
du document. Ce dernier obeit a des regies tres precises de comptage des balises afin 
que, d'une revision a l'autre, un meme nombre represente une meme position dans 
l'arbre XML. 

C'est sur cette derniere consideration que nous quittons la presentation du modele de 
gestion des revisions utilise dans la documentation technique de l'aviation civile. 



Exemple base sur ('utilisation des URN 



Dans le modele S1000D, de type modulaire, on precede a la gestion des revisions au 
travers d'indicateurs places sur quelques elements choisis : ceux qui constituent le 
corps textuel du module et dont le modele de contenu n'est pas mixte. C'est le cas des 
titres, lignes de tableaux, alineas (un niveau de liste donne), figures completes, para- 
graphes seuls, etc. La marque de revision est posee via l'attribut change qui prend les 
valeurs suivantes : 

• add si la balise est nouvelle par rapport a la version precedente du module, 

• mod si un attribut ou le contenu de la balise a ete modifie, 
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• del si une balise a ete supprimee. L'attribut change est alors porte par le parent de 
celle qui a ete supprimee. 

II a ete decide que les identifiants des ressources qui sont des cibles potentielles de liens 
resteraient constants meme en cas devolution de leur contenu, cela afin d'eviter les 
problemes de propagation aux liens des changements d'indice de revision des modules 
de donnees (probleme expose au chapitre 6). Ainsi, les identifiants des modules (le 
DMC), publication (le TPC) et illustration (1'ICN) restent inchanges tout au long de 
la vie de ces objets, et tous les liens les referencant sont constamment valides. 

Avec l'avenement du Web, le mecanisme d'adressage par les URL (Uniform 
Resource Locators) a permis de definir une methode d'acces a des ressources situees 
n'importe ou geographiquement. 

Helas, les URL etablissent des liens directs vers une localisation physique donnee, et 
les consequences en sont importantes. En effet, si la ressource change de place, le lien 
est perdu, et cela donne lieu au message d'erreur standard 404 precisant que la cible 
n'a pas ete retrouvee. De meme, pour positionner un lien en utilisant les URL, la loca- 
lisation physique de la cible doit etre connue a l'avance, ce qui n'est pas toujours le cas. 

Des solutions ont ete elaborees pour definir des mecanismes de liaisons independants 
de la localisation physique des ressources. Ceux de la S1000D font intervenir les 
Uniform Resource Names (URN), ou noms uniformes de ressources. 

Introduction aux URN 

Par le biais de 1'IETF, la communaute Internet a depuis longtemps exprime le besoin 
de disposer d'un schema d'adressage logique des ressources. II en est resulte en 1997 
la RFC 2141 qui normalise les noms uniformes de ressources. Avec les URN, les res- 
sources sont identifiees par une cle invariante, ensuite resolue par un serveur de loca- 
lisation capable de retrouver la localisation physique reelle de la ressource. 

Bien que cet adressage independant reponde sur le principe au besoin, son develop- 
pement en tant que methode standardised pour la resolution de la localisation des 
ressources s'est neanmoins fait attendre, et ce en grande partie en raison de l'incom- 
patibilite technique des solutions developpees : Persistent URL ou PURL, Basic 
URN Service resolution ou BURNS, ou encore Trivial HTTP ou THTTP. 

PURL est une methode de catalogage des ressources Internet developpee par 
l'OCLC, un service de catalogage de librairies Internet qui repose lui-meme sur un 
service web capable de retourner une adresse physique a partir d'une adresse logique. 
Cette methode ne repond malheureusement pas vraiment au probleme pose par la 
resolution des liens dans une documentation modulaire. 
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BURNS est un serveur HTTP d'URN resolus reposant sur une base de donnees 
X.500 developpee par le DTSC de l'Universite de Queensland en Australie. L'un des 
interets de la methode est l'utilisation des URC, ou Uniform Resources Characteris- 
tics, pour recuperer les metadonnees de type Dublin Core (voir chapitre 11) asso- 
ciees aux ressources. 

Nous allons maintenant donner quelques explications techniques complementaires, 
notamment des definitions, relativement aux URN. 

Ressources, URN, URI et URL 

L'un des fondements du World Wide Web est la notion de ressource. Une ressource 
est une entite informatique quelconque adressee via un identifiant. Ce dernier peut 
etre un nom logique (il s'agit alors d'un URN) ou une localisation physique (une 
adresse URL). Ces deux types d'adressage ont des syntaxes qui sont des variantes 
d'une meme syntaxe generique : celle des identifiants uniformes de ressources du 
Web ou URI (Uniform Ressource Identifier). 

La syntaxe des URI est specifiee par la RFC IETF 2396 d'aout 1998. Les syntaxes 
particulieres des URL et des URN sont respectivement specifiees par les RFC 1738 
de decembre 1994, et2141 de mai 1997. 

Serveur de ressources 

La resolution des ressources requiert que soit determined leur localisation physique a 
partir d'un URI. Un serveur de ressources a ainsi pour fonction de reconnaitre la syn- 
taxe de l'URI recu, de determiner s'il s'agit d'un URN ou d'une URL. Dans le cas 
d'une URL, le serveur donne directement acces a la ressource, tandis que dans celui 
d'un URN il doit activer le service capable d'en fournir FURL. 

Metadonnees 

La gestion des acces aux ressources via des adresses logiques n'a de sens que si le ser- 
veur de ressources dispose d'un minimum d'intelligence pour les retrouver, par 
exemple pour retrouver la bonne version de la ressource a utiliser. C'est ici que les 
metadonnees de gestion associees aux ressources prennent toute leur importance. 

Nous avons vu au chapitre 12 le modele de metadonnees qui est utilise par la norme 
S1000D. 

Le serveur de ressources est un programme qui doit etre capable de resoudre les 
URN en executant des recherches sur les metadonnees des ressources. 

Format des URN 

Le format des URN repond a la syntaxe URN : NID : NSS, dans laquelle : 
• URN : est un prefixe obligatoire. 
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• NID : est l'identifiant d'un espace de noms (Namespace IDentifier). 

• NSS : est la chaine d'identification de la ressource a l'interieur de l'espace de noms 
(Namespace Specific String). 

Pour la S1000D, l'identifiant de l'espace de noms des ressources, le NID, est naturel- 
lement le mot S1000D. 

Pour la partie NSS, les codes des modules de donnees (ou DMC comme Data 
Module Code), des publications (ou TPC comme Technical Publication Code) et 
enfin des illustrations (ou ICN comme Illustration Code Number) sont utilises ; ce 
qui, au final, donne les trois possibilites de codification suivantes pour la S1000D : 

URN:S1000D:DMC 
URN:S1000D:TPC 
URN:S1000D:ICN 

Bien que les systemes de codification des DMC, TPC et ICN soient semblables, un 
serveur de ressources doit savoir les differencier. Le principe visant a utiliser les mots 
DMC, TPC et ICN comme prefixes de la partie NSS a aussi ete retenu. Les URN 
sont des lors structures ainsi : 

URN:S1000D:DMC-{DMC selon la syntaxe S1000D} 
URN:S1000D:TPC-{TPC selon la syntaxe S1000D} 
URN:S1000D:ICN-{ICN selon la syntaxe S1000D} 

Par exemple, voici TURN correspondant au DMC AE-A-00-40-05-50A-000A-A : 
URN : S1000D: DMC-AE-A-00-40-05-50A-OOOA-A 

Enfin, cette syntaxe est completee au besoin d'un numero de revision et d'un code 
langue identifies respectivement par les chaines _I-{ISSUE} et _L-{LANC} ou {ISSUE} 
et{LANG}. 

Par exemple, voici TURN de la version 2 anglaise du module dont le DMC est 
AE-A-00-40-05-50A-000A-A : 



I 



URN : S1000D: DMC-AE-A-00-40-05-50A-000A-A_I-2_L-EN 



Liens realises au moyen des URN 

Dans la S1000D, les liens sont specifies en utilisant le vocabulaire de Xlink. 
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Dans ce premier exemple, le lien est une reference a un module : 

<refdm xlink: type="simple" 

xl i nk: actuate="onRequest" 

xlink: show=" replace" 

xlink: title="IETP-X Resolution de Ressource" 

xl i nk: href="URN : S1000D : DMC-AE-A-00-40-50-50A-OOOA-A"> 
<avee> 

<model i c>AE</model i c> 

<sdc>00</sdc> 

<chapnum>00</chapnum> 

<section>4</section> 

<subsect>0</subsect> 

<subject>05</subject> 

<di scode>50</di scode> 

<di scodev>A</di scodev> 

<i ncode>000</i ncode> 

<i ncodev>A</i ncodev> 

<i teml oc>A</i teml oc> 
</avee> 
</refdm> 

Dans ce deuxieme exemple, le lien est une reference a une publication : 

<reftp xlink: type="simple" 
xl i nk: actuate="onRequest" 
xlink: show=" replace" 
xlink:title="Exemple IETP-X" 
xlink:href="URN:S1000D:TPC-lB-B-AMP-27-I">TPC-lB-B-AMP-27-I</reftp> 

Dans ce troisieme exemple, le lien est une reference a un graphique : 

<figure id="fig001"> 

<title>Visualisation tete basse</title> 
<graphic xlink:type="simple" 
xl i nk: actuate="onLoad" 
xl i nk : show="embed" 

xlink:href="URN:S1000D:ICN-lA-B-311501-B-F6117-00352-A-01-l" 
boardno="ICN-lA-B-311501-B-F6117-00352-A-01-l"/> 
</figure> 

Pour convertir un URN en nom de fichier adressable, une methode de resolution 
simple consiste a recuperer la chain e correspondant a la valeur NSS de TURN, a lui 
ajouter l'extension appropriee (XML, CGM, JPG...), et eventuellement a ajouter 
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une structure statique de repertoires afin de creer une URL relative ou statique. Une 
application plus complexe utilisera une base de donnees pour retrouver l'URL corres- 
pondant a un URN specifique. 

Service Web pour resoudre les URN 

Pour etre transformes en URL de maniere standard et uniforme, les URN sont 
envoyes a un serveur de ressources qui active un programme de transcodage. II s'agit 
typiquement d'un service Web acceptant des requetes du genre : 

http://urn. server.com/urnServiceName?urnQueryString 

ou : 

• urn.server.com estle DNS du serveur de resolution. 

• urnServi ce est le nom du service de resolution d'URN. 

• urnQueryString est la requete de transcodage. 

Un tel service web n'est pas limite au transcodage des URN en URL mais repond 
egalement aux requetes d'interrogation sur les metadonnees : soit parce qu'il possede 
les methodes d'acces a la base de donnees qui les gere, soit parce que, connaissant les 
adresses physiques des ressources, il est capable d'aller y puiser les valeurs des meta- 
donnees demandees. 

Quand un couple nom/valeur est specifie, cela signifie que la requete est qualifiee par 
des precisions quant a la valeur des metadonnees. Dans l'exemple 1 ci-apres, on 
demande l'URL de la version anglaise d'une ressource. 

Exemple 1 : pour retrouver l'URL en version anglaise d'un URN : 
http : //urn . server . com/urnServi ce?urn=URN : NID : NSS&l ang=EN 

Quand un nom de caracteristique est transmis au service web sans valeur associee, 
cela signifie que la requete interroge le service web sur cette caracteristique. Dans 
l'exemple 2 ci-apres, on cherche a obtenir le nom d'un auteur, et dans l'exemple 3 on 
s'enquiert simplement de l'URL d'une ressource. 

Exemple 2 : pour retrouver la valeur de la caracteristique auteur de la version 
anglaise d'une ressource : 

I http : //urn . server . com/u rnServi ce?u ri =URN : NID : NSS&author&l ang=EN 

Exemple 3 : retourne l'URL de la version anglaise d'une ressource : 
http : //urn. server. com/u rnService?urn=URN: NID :NSS&url&lang=EN 
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Le mot-cle allures, comme all URC (Uniform Ressource Characteristics), signifie 
que Ton demande au service toutes les metadonnees de la ressource specifiee, comme 
dans l'exemple 4 : 

Exemple 4 : pour retrouver la valeur de toutes les caracteristiques d'une ressource : 
http://urn.server.com/urnService?uri=URN:NID:NSS&al lures 

Exemple 5 : requete permettant de savoir si deux URN sont equivalentes : 
http : //urn . server . com/urnServi ce?urn=URN : NID : NSSl&urn=URN : NID: NSS2 

On comprendra que, avec cette approche, le serveur d'URN est proche des fonctions 
de GED (Gestion electro nique des documents). 

Exemple concret 

Le tableau suivant contient une serie d'equivalences URN/URL, completers des meta- 
donnees titre et langue. La colonne « Defaut » indique l'URL considered par defaut 
pour les requetes sans precision sur un URN auquel sont associees plusieurs URL. 

Tableau 13-1 Exemple de donnees 





URL 


Titre 


Langue 


Defaut 


URN:S1000D:DMC-999-A 


www.ex.com/ 
*-DMC-999-A.XML 


Title 1 


EN 





URN:S1000D:DMC-520-A 


www.ex.com/ 

DMC-520-A_L-EN.XML 


Title 2 


EN 





URN:S1000D:DMC-520-A 


www.ex.com/ 

DMC-520-A_L-FR.XML 


Titre 2 


FR 


N 


URN : S1000D : DMC-520-AJ.-EN 


www. ex. com/ 

DMC-520-A_L-EN.XML 


Title 2 


EN 





URN:S1000D:DMC-520-A_L-FR 


www.ex. com/ 

DMC-520-A_L-FR.XML 


Titre 2 


FR 





URN:S1000D:ICN-00352 


www.ex.com/ 
*»ICN-00352.CGM 


GraTitle 1 


EN 






Void la requete appropriee pour etre redirige sur l'URL associee a 
URN:S1000D:DMC-999-A: 

http : //www. ex . com/resol ution/resol veUrn?urn=URN : S1000D : DMC-999-A 
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Elle redirige vers l'URL 

I http://www.ex.com/DMC-999-A.XML. 



Void maintenant la requete pour renvoyer la caracteristique ti tl e de la ressource 
URN:S1000D:DMC-999-A: 

I http : //www. ex . com/resol ution/resol veUrn?urn=URN : S1000D : DMC-999-A&ti tl e 

Elle renvoie le document XML suivant : 

<rds> 

<rdu scheme="dc"> 
<rdf : rdf> 
<rdf : Descri pti on rdf : about="URN : S1000D : DMC-999-A"> 

<urc name="titre">Title l</urc> 
</ rdf : descri pti on> 
</rdf : rdf> 
</rdu> 
</rds> 

La requete qui porte sur URN : S1000D: DMC-520-A, sans precision alors qu'il existe plu- 
sieurs URL associees : 

http : //www. ex . com/resol ution/resol veUrn?urn=URN : S1000D : DMC-520-A 

redirigera vers la ressource par defaut : 
http://www.ex.com/DMC-520-A_L-EN.XML 

En revanche, si une specification sur la metadonnee langue est fournie : 

http : //www. ex . com/resol ution/resol veUrn?urn=URN : S1000D : DMC-520- 
A&langue=FR 

c'est l'URL de la ressource francaise qui sera choisie : 
http://www.ex.com/DMC-520-A_L-FR.XML 

Avec le mot-cle multiple, la requete retourne les metadonnees demandees de toutes 
les ressources associees a un URN. Dans l'exemple qui suit, la valeur de la meta- 
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donnee title est demandee pour toutes 
URN:S1000D:DMC-520-A. 



les 



ressources associees 



http ://www. ex . com/resol ution/resol veUrn?urn=URN : S1000D : DMC-520- 
A&multiple&title 

Cette requete retourne le document XML suivant : 

<rds> 

<rdu scheme="dc"> 
<rdf : rdf> 
<rdf : Descri pti on rdf : about="URN : S1000D : DMC-520-A"> 

<urc name="titre">Title 2</urc> 
</rdf : descri pti on> 
</rdf : rdf> 
</rdu> 

<rdu scheme="dc"> 
<rdf : rdf> 
<rdf: Descri pti on rdf : about="URN : S1000D : DMC-520-A"> 

<urc name="titre">Titre 2</urc> 
</rdf : descri pti on> 
</rdf : rdf> 
</rdu> 
</rds> 

En utilisant allures, la requete suivante retourne les valeurs de toutes les metadon- 
nees de la ressource associee a URN : S1000D: DMC-999-A : 

http : //www. ex . com/resol ution/resol veUrn?urn=URN : S1000D : DMC-999- 
A&allurcs 

Cette requete renvoie le document XML suivant : 

<rds> 

<rdu scheme="dc"> 
<rdf : rdf> 
<rdf: Descri pti on rdf : about="URN : S1000D : DMC-999-A"> 
<u re name="u rl ">http : //www . ex . com/DMC-999-A . XML</u rc> 
<urc name="titre">Title l</urc> 
<urc name="langue">EN</urc> 
</ rdf : descri pti on> 
</rdf : rdf> 
</rdu> 
</rds> 
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La requete qui retoume simplement FURL d'une ressource utilise le parametre url : 
http : //www. ex . com/resol ution/resol veUrn?urn=URN : S1000D : ICN-00352&url 

Cette requete renvoie le document XML suivant : 

<rds> 

<rdu scheme="dc"> 
<rdf : rdf> 
<rdf: Description rdf :about="URN:S1000D:ICN-00352"> 

<urc name="URL">http : //www . ex . com/ICN-00352 . CCM</u rc> 
</rdf :description> 
</rdf : rdf> 
</rdu> 
</rds> 

Pour resumer, les URN permettent de gerer les revisions uniquement si l'une ou 
l'autre des deux conditions suivantes est reunie : 

1 Lindice de revision est code dans l'identifiant de ressource cible. 

2 Lindice de revision de la ressource cible est code a l'exterieur du document, au 
niveau du serveur de resolution d'adresses URN. 



Autres methodes de gestion des revisions 

II existe au moins trois autres approches que nous ne ferons qu'evoquer ici : 

• l'approche base de donnees XML, 

• l'approche par calcul differentiel XUpdate, 

• l'approche base de donnees relationnelle. 

L'approche base de donnees XML 

Cette approche consiste a charger le document dans une base de donnees en compa- 
rant nceud apres noeud l'egalite de la nouvelle version avec l'ancienne. 

En cas d'egalite, l'ancienne structure est conservee. En cas d'inegalite des nceuds, 
une nouvelle branche est creee dans la base. 

Un arbre multidimensionnel, dit « multitemporel », se construit ainsi petit a petit. II 
represente toutes les evolutions subies par les noeuds au fil du temps. N'importe 
quelle version du document peut etre reconstruite a tout moment. 
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Dans cette approche, l'utilisateur qui produit un document XML ne s'occupe nulle- 
ment de marquer ses revisions. II se contente de modifier le document et de 
l'importer dans la base. C'est le systeme qui detecte seul les differences avec la ver- 
sion precedente, creant dans la base et de maniere invisible pour l'utilisateur les mar- 
ques correspondantes. 

L'utilisateur peut a tout moment demander 1' extraction de n'importe quelle version, 
ce qui ne signifie pas pour autant que les balises de revision seront introduites dans le 
document. 



L'approche par calcul differentiel XUpdate 

Cette approche est similaire a la precedente sauf que les documents XML revises 
font l'objet d'une transformation importante au terme de laquelle le document est 
exprime uniquement a l'aide d'un balisage servant a marquer les differences entre 
l'ancienne et la nouvelle version. 

Pour cela, il « suffit » de calculer l'equivalent XUpdate des modifications effectuees 
dans le document originel. En effet, XUpdate est un langage XML qui permet de 
specifier des ordres de modifications de documents XML. 

Par exemple, le programme Xupdate suivant ajoute I'element address apres celui 
correspondant au chemin d'acces Xpath : /addresses/address [1] (repere©). 
Ensuite, le programme ajoute un attributid a I'element nouvellement cree 
(repere O), puis ajoute enfin a l'identique les lignes reperees ©. 



<?xml version="1.0"?> 

<xupdate: modifications version="1.0" xmlns :xupdate. . .> 
<xupdate: insert-after select="/addresses/address[l] "> <- 
<xupdate: element name="address"> 

<xupdate: attribute name="id">2</xupdate:attribute> <- O 
<fu"l"lname>Lars Marti n</fu"l~lname> <- © 

<born day='2' month='12' year=' 1974 '/> <- © 
<town>Leizig</town> <- © 

<country>Germany</country> <- © 

</xupdate : el ement> 
</xupdate: insert-after> 
</xupdate : modi f i cati ons> 

Puis, il ajoute un bloc de donnees entier au document XML suivant : 

<?xml version="1.0"?> 
oddresses version="1.0"> 
<address id="l"> 
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<f ul 1 name>Andreas Laux</f ul 1 name> 
<born day='l' month='12' year=' 1978 '/> 
<town>Lei pzi g</town> 
<country>Germany</country> 
</address> 
</addresses> 

qui devient : 

<?xml version="1.0"?> 
oddresses version="1.0"> 
<address id="l"> 

<f ul 1 name>Andreas Laux</f ul 1 name> 

<born day='l' month='12 ' year=' 1978 '/> 

<town>Lei pzi g</town> 

<country>Germany</country> 
</address> 
oddress id="2"> 

<fullname>Lars Marti n</f ul 1 name> 

<born day='2' month='12' year=' 1974 '/> 

<town>Lei zi g</town> 

<country>Cermany</country> 
</address> 
</addresses> 

L'inverse est vrai. Des produits permettent de stacker les revisions de documents 
XML sous la forme de programmes XUpdate : ils identifient les differences entre 
deux versions d'un meme document XML, puis en deduisent le programme 
XUpdate correspondant. C'est alors le programme qui est conserve dans la base. 

L'approche base de donnees relationnelle 

Les bases de donnees relationnelles sont de mauvaises candidates au stockage des 
documents XML, en particulier, lorsque ces derniers contiennent des modeles 
mixtes, font appel a des espaces de noms variants et... quand il faut stacker plusieurs 
versions d'un meme document XML dans la base. 

La seule solution consiste a utiliser un modele de table simple et a debiter le docu- 
ment XML en petits morceaux pour le faire tenir dans des champs elementaires de la 
base de donnees. 

Cette approche presente l'avantage de pouvoir stacker et identifier le moindre des 
caracteres modifies entre deux versions d'un meme fichier XML, ce que ne peuvent 
faire les approches basees sur la logique XML. Certains caracteres echappent com- 
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pletement a cette logique : il s'agit en particulier des blancs compris entre deux 
balises, au debut ou a la fin du contenu d'un element, des retours a la ligne, des carac- 
teres accentues qui peuvent etre ecrits tantot sous leur forme Unicode (par exemple 
« e ») et tantot sous forme d'entite (é). 

Dans le cas ou il faut vraiment identifier la moindre des modifications apportees a un 
document XML, la solution la plus appropriee est celle du tronconnage ou debitage 
mecanique. Elle consiste a eclater le document en autant de petits bouts qu'il y a de 
balises XML, de contenus textuels et d'interstices entre les balises. 

Par exemple, le tronconnage du document precedent occasionnera les bouts pre- 
sented au tableau 13-2. Dans ce tableau, les numeros des noeuds correspondent a la 
methode de calcul des identifiants de nceuds presentee au chapitre 4. 







Tableau 13-2 Comparaison de deux documents XML 


par tronconnage 




Document d'origine 
N° ss-N° Typed'objet Valeur 




Document modifie 
N° ss-N° Typed'objet Valeur 


1,12 


1 


Element addresses 




1,22 


1 


Element addresses 




2 


Norn d'attribut 


version 




2 


Norn d'attribut 


version 




3 


Valeur d'attribut 


1.0 




3 


Valeur d'attribut 


1.0 




4 


Espace inter-unites 


\n 




4 


Espace inter-unites 


\n 


2,11 


1 


Element 


address 


2,11 


1 


Element 


address 




2 


Norn d'attribut 


Id 




2 


Norn d'attribut 


Id 




3 


Valeur d'attribut 


1 




3 


Valeur d'attribut 


1 




4 


Espace inter-unites 


\n 




4 


Espace inter-unites 


\n 


3,4 


1 


Element 


fullname 


3,4 


1 


Element 


fullname 




2 


Contenu textuel 


Andreas Laux 




2 


Contenu textuel 


Andreas Laux 




3 


Espace inter-unites 


\n 




3 


Espace inter-unites 


\n 


5,6 


1 


Element 


born 


5,6 


1 


Element 


born 




2 


Norn d'attribut 


day 




2 


Norn d'attribut 


day 




3 


Valeur d'attribut 


1 




3 


Valeur d'attribut 


1 




4 


Norn d'attribut 


month 




4 


Norn d'attribut 


month 




5 


Valeur d'attribut 


12 




5 


Valeur d'attribut 


12 




6 


Norn d'attribut 


year 




6 


Norn d'attribut 


year 




7 


Valeur d'attribut 


1978 




7 


Valeur d'attribut 


1978 




8 


Espace inter-unites 


\n 




8 


Espace inter-unites 


\n 


7,8 


1 


Element 


town 


7,8 


1 


Element 


town 




2 


Contenu textuel 


Leipzig 
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Tableau 13-2 Comparaison de deux documents XML 


par tronconnage 




Document d'origine 
N° ss-N° Typed'objet Valeur 




Document modifie 
N° ss-N° Typed'objet Valeur 




3 


Espace inter-unites 


\n 






2 


Contenu textuel Leipzig 


9,10 


1 


Element 


country 




3 


Espace inter-unites 


\n 




2 


Contenu textuel 


Germany 


9,10 


1 


Element 


country 




3 


Espace inter-unites 


\n 




2 


Contenu textuel 


Germany 












3 


Espace inter-unites 


\n 










12,11 


1 


Element 


address 












2 


Norn d'attribut 


Id 












3 


Valeur d'attribut 


2 












4 


Espace inter-unites 


\n 










13,14 


1 


Element 


fullname 












2 


Contenu textuel 


Lars Martin 










15,16 


1 


Element 


born 












2 


Norn d'attribut 


day 












3 


Valeur d'attribut 


2 












4 


Norn d'attribut 


month 












5 


Valeur d'attribut 


12 












6 


Norn d'attribut 


year 












7 


Valeur d'attribut 


1974 












8 


Espace inter-unites 


\n 










17,18 


1 


Element 


town 












2 


Contenu textuel 


Leipzig 












3 


Espace inter-unites 


\n 










19,20 


1 


Element 


country 












2 


Contenu textuel 


Germany 












3 


Espace inter-unites 


\n 



Ainsi « aplatis », il est possible de comparer les deux tableaux et de se mettre en quete 
des differences. Un tel resultat peut facilement etre transpose dans un modele rela- 
tionnel. 

Cette approche a l'avantage de fonctionner simplement et efficacement. Le cas 
echeant, les documents seront prepares avant leur introduction dans la base. Le pro- 
bleme est que Ton a alors une liste de micro-differences qui ne permet pas de verita- 
blement gerer les revisions. 



_ Modeles de reference 

Deuxieme partie 



En resume 



Dans ce chapitre, nous avons vu comment aborder le delicat probleme de la gestion 
des revisions. Dans ce domaine, XML n'est pas forcement simple d'utilisation. 

Principalement, il y a le choix entre : 

• Marquer les revisions par un balisage specifique a l'interieur du document XML. 
La gestion se fait alors a priori. 

• N'utiliser aucun marquage particulier et laisser des programmes calculer les diffe- 
rences entre les versions. La gestion des revisions s'effectue alors a posteriori. 

Nous avons vu que la premiere approche pose un serieux probleme de conception des 
schemas et oblige a adopter des strategies de gestion des revisions bien identifiees. 

La seconde approche requiert que Ton dispose d'un outil ad hoc. Pour que les revi- 
sions puissent etre mises en evidence lors de l'affichage ou la publication d'un docu- 
ment, il faudra alors que l'outil sache mettre dans le document le bon balisage (il ne 
suffit pas de savoir le calculer). Cette approche ne posera toutefois pas de probleme 
de modelisation. Pour l'affichage ou la publication d'un document, on peut toujours 
se contenter d'une forme bien faite : il n'est pas necessaire que cette forme soit valide. 

Enfin, nous avons vu l'impact de la gestion des revisions sur les liens : la encore, des 
choix importants de conception devront etre faits. 

Par nature, les donnees de revisions et de versions ne se situent pas sur le meme plan 
que les donnees et la structure des documents XML eux-memes. Une gestion limitee 
des revisions peut etre etablie a l'aide de balises respectant la separation entre les 
donnees de versions et les donnees XML, comme l'a montre le modele ATA. Cepen- 
dant, une veritable gestion des revisions doit faire appel a des programmes ou des 
applications dediees telles que les bases de donnees XML. 



A 

Representation UML avancee 

pour XML Schema 



Nous presentons dans cette annexe les notations UML a utiliser en regard de tous les 
mecanismes autorises mais avances de XML Schema. Nous analysons chaque diffi- 
culte et expliquons comment la traiter. Nous avons baptise « avances » les meca- 
nismes de XML Schema rarement utilises et dont on peut meme se demander s'ils 
doivent raisonnablement etre representes dans les vues UML du systeme. 

Void les mecanismes avances de XML Schema dont on trouvera ici la 
correspondance UML : 

• les attributs et les types listes et unions, 

• les attributs et autres valeurs par defaut, 

• la definition d'annotations, 

• les groupes d'attributs, 

• les contraintes d'exclusion et les groupes de choix, 

• les contraintes de simultaneite et les groupes simples, 

• la question de l'ordre des elements, 

• la mixite des modeles. 
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Attributs et types listes de XML Schema 



UML autorise a specifier tant une multiplicite maximale qu'une multiplicite mini- 
male pour les attributs UML. Les multiplicites servent a indiquer des contraintes sur 
le nombre de valeurs que doit avoir un attribut. La multiplicite minimale induit les 
contraintes suivantes : 

• Lorsque la multiplicite minimale est egale a 0, 1' attribut est optionnel. 

• Lorsque la multiplicite minimale est egale a 1, l'attribut est obligatoire. 

• Lorsque la multiplicite minimale est superieure a 1, l'attribut est une liste ayant 
un nombre de valeurs obligatoires egal a la valeur de la multiplicite minimale. 

Par defaut, la multiplicite minimale est egale a 0. 

La multiplicite maximale induit les contraintes suivantes : 

• Lorsque la multiplicite maximale est egale a 1, l'attribut a une seule valeur. 

• Lorsque la multiplicite maximale est superieure a 1, l'attribut est une liste de 
valeurs. 

Par defaut, la multiplicite maximale est egale a 1. 

Pour savoir si un attribut a une seule valeur ou s'il est une liste, il suffit de regarder sa 
multiplicite maximale. La multiplicite minimale n'indique, quant a elle, que le 
nombre de valeurs obligatoires. 

Les regies de representation d'un attribut UML en XML dependent du type de don- 
nees de l'attribut et du choix de transformation des attributs en XML. 

• Lorsqu'un attribut est de type compose, par exemple un type adresse avec rue, 
ville et code postal, l'attribut UML est obligatoirement represente par un 
element XML. 

• Lorsqu'un attribut est de type simple, il peut au choix etre represente par un attri- 
but XML ou par un element XML. Le choix releve d'une decision de conception 
des schemas XML. 

Lorsqu'un attribut UML est represente par un element XML, les valeurs des multi- 
plicites minimale et maximale correspondent aux indicateurs d'occurrences de 
1' element : minOccur, maxOccur. 

Lorsqu'un attribut UML est represente par un attribut XML, le type associe a 
l'attribut XML varie en fonction des valeurs des multiplicites. En effet, il n'est pas 
possible, en XML, de definir des indicateurs d'occurrences pour les attributs. En 
XML, un element ne peut avoir qu'un seul attribut d'un nom donne. En revanche, 
cet attribut peut avoir une suite de valeurs. II faut alors recourir au type liste de 
XML Schema. Le tableau Al-1 donne la liste des combinaisons possibles. 
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Tableau A-1 Representation d'un attribut UML par un attribut XML 


Exemple UML Multiplicity Multiplicity 


Attribut XML Exemple XML 


minimale maximale 









1 


Attribut de type <xs:simpleType name="telephoneType"> 
simple non obliga- <xs: restri ctionbase="xs: stri ng"/> 


partenaire0..1 


+telephone[0..1]: 
tele phone Type 


toire 


</xs:simpleType> 










<xs : el ement name="partenai re"> 










<xs:complexType> 










<xs: attribute 










name="telephone" 










type="telephoneType" 










use="optional "/> 










</xs:complexType> 










</xs:element> 




1 


1 


Attribut de type <xs:simpleType naitie="telephoneType"> 
simple obligatoire <xs : restri ctionbase="xs : stri ng"/> 
</xs:siinpleType> 


partenaire 1..1 


+telephone[1 ..1]: 
tele phone Type 










<xs : el ement name="partenai re"> 










<xs:complexType> 










<xs: attribute 










name="telephone" 










type="telephoneType" 










use="required"/> 










</xs : compl exType> 










</xs:element> 







* 


Attribut de type <xs:simpleType naine="telephoneType"> 
liste <xs: restri ctionbase="xs: stri ng"/> 


partenaire 0..' 


+telephone[0.*]: 
tele phone Type 




</xs:siinpleType> 










<xsd : si mpl eType name="tel Li ste"> 










<xsd : 1 i st i temType="tel ephoneType"/> 










</xsd:simpleType> 










<xs : el ement name="partenai re"> 










<xs: compl exType> 










<xs: attribute 










name="telephone" 










type="tel Liste" 










use="reguired"/> 










</xs : compl exType> 










</xs:element> 
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Tableau A-1 Representation d'un attribut UML par un attribut XML 

Exemple XML 



ExempleUML Multiplicity Multiplicity Attribut XML 
minimale maximale 




partenaire0..4 



+telephone[0..4J 
telephon eType 



partenaire 3.. 4 



+telephone[3..4]: 
tElephoneType 



>0 



>1 

+ 

Valeur limite 



Attribut de type <xs:simpleType name="telephoneType"> 
liste avec facette <xs: restrictionbase="xs:string"/> 
maxLength </xs:simpleType> 



<xs : si mpl eType name="tel Li ste"> 
<xs : 1 i st i temType="tel ephoneType"/> 
</xs:simpleType> 

<xs: si mpl eType 

name="tel Li steMaxQuatre"> 

<xs: restriction base="telList"> 

<xs: maxLength value="4"/> 

</xs: restriction> 
</xs:simpleType> 

<xs: element name="partenai re"> 
<xs:complexType> 
<xs: attribute 

name="telephone" 
type="tel Li steMaxQuatre" 
use="requi red"/> 
</xs : compl exType> 
</xs:element> 



>1 



Valeur limite Valeur limite 



Attribut de type <xs: si mpl eType name= 
liste avec facettes <xs: restrictionbase= 
maxLength et min- </xs:simpleType> 
Length 



'telephoneType"> 
'xs:string"/> 



<xs : si mpl eType name="tel Li ste"> 
<xs : 1 i st i temType="tel ephoneType"/> 
</xs:simpleType> 

<xs: si mpl eType 

name="tel Li steMi nMax"> 
<xs: restriction base="telList"> 
<xs:minLength value="3"/> 
<xs: maxLength value="4"/> 
</xs: restriction> 

</xs:simpleType> 

<xs: element name="partenaire"> 
<xs: compl exType> 
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Tableau A-1 Representation d'un attribut UML par un attribut XML 



Exemple UML Multiplicity Multiplicity Attribut XML 
minimale maximale 


Exemple XML 










<xs: attribute 












name="telephone" 












type="tel Li steMi nMax" 












use="required"/> 
</xs : compl exType> 
</xs:element> 





A la lecture du tableau A-1, on aura pu noter que la correspondance UML/XML 
n'est pas directe. Ce qui est specifie au niveau de l'attribut dans UML Test au niveau 
du type de l'attribut dans XML. 

En ce qui concerne le type union de XML Schema, on ne trouve pas de representa- 
tion correspondante dans UML. XML Schema dispose de capacites d'expression 
plus avancees en ce qui concerne le controle des valeurs d'attributs et d'elements. 



Attributs et valeur par defaut 

II est possible de donner une valeur par defaut aux attributs UML. La correspon- 
dance de ces valeurs par defaut en XML est donnee dans le tableau A-2. 



La definition d'annotations 

UML permet de definir des commentaires sur tout objet de modelisation. A chaque 
commentaire associe a un objet UML correspond dans le schema XML une annota- 
tion XML de type documentation. 



Groupe d'attributs 

La notion de groupe d'attributs n'existe pas en UML. Le concept le plus proche est 
celui de type de donnees (DataType en anglais) avec la restriction suivante : les attri- 
buts du type de donnees doivent eux-memes etre de type simple, c'est-a-dire ne pas 
se decomposer en d'autres attributs. Pour exprimer l'utilisation d'un groupe d'attri- 
buts par une classe, il faut utiliser une relation de generalisation entre la classe et le 
type de donnees. 
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Tableau A-2 Valeur d'attribut par defaut 




Attribut avec 


valeur par defaut 




Cas oil I'attribut UML donne lieu a un element XML 

<xs: element name="restaurant"> 
<xs : compl exType> 
<xs :sequence> 

<xs: element name="menu" 

type = "xs: string" 
default="truite meuniere"/> 
</xs:sequence> 
</xs:c omplexType> 
</xs :element> 

Cas oil I'attribut UML donne lieu a un attribut XML 
<xs : el ement name="partenai re"> 
<xs : compl exType> 
<xs : attribute 
name="menu" 
type="xs : string" 
value="trui re meuniere"/> 
</xs : compl exType> 
</xs:element> 




restaurant 




+menu:string=truite meuniere 









Modele UML 










Une classe et ses commentaires 










Un premier 


^ 




Pilot* 


















un acLKifrnc 
tommentaire 



















Tableau A-3 Annotations 

Representation XML 

Annotation XML 



<xs: el ement name="pilote"> 
<xs:annotation> 

<xs:documentation>Un premier 
commentai re 

</xs : documentati on> 
<xs:documentation>Un deuxieme 
commentai re 

</xs : documentati on> 
</xs:annotation> 
<xs: compl exType> 

</xs : compl exType> 
</xs :element> 



Sur le plan de la conformite a UML, cette relation de generalisation entre une classe 
et un type de donnees est inhabituelle, mais ne viole pas les regies de generalisation 
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etablies par la norme UML 2.0. Si Ton avait considere le groupe d'attributs comme 
une classe standard, nous aurions ete confrontes a des difficultes pour la transposi- 
tion du modele de classe vers le modele XML. Au chapitre 3, nous avons vu que, 
dans le cas general, chaque classe donne lieu a un element XML ; or ce n'est pas ce 
que nous recherchons ici, les groupes d'attributs n'etant justement pas des elements 
XML Schema. 

Tableau A-4 Groupe d'attributs 

Modele UML 

Une classe heritant d'un type de donnees 



«DataType» 




<<Enumeration>> 


ItemDelivery 




shipBy 


+partNum:SKU 


+air 


+shipBy:shipBy 




+any 


+weightKg:Decimal 

A 




+land 


T 

Item 




+productName:string 




+quantity:positivelnteger 




+shipDate:Date 




+USPrice:Decimal 




+partNum:SKU 




+shipBy:shipBy 




+weightKg:Decimal 







Representation XML 

Groupe d'attributs XML 

<xsd:attributeGroup name="ItemDeli very"> 
<xsd: attribute name="partNum" type="SKU"/> 
<xsd : attri bute name="wei ghtKg" 

type="xsd: decimal "/> 
<xsd: attri bute name="shipBy"> 
<xsd : si mpl eType> 
<xsd : restri ction base="xsd : stri ng"> 
<xsd : enumerati on val ue="ai r"/> 
<xsd : enumerati on val ue="l and"/> 
<xsd : enumerati on val ue="any"/> 
</xsd: restri ction> 
</xsd : si mpl eType> 
</xsd : attri bute> 
</xsd : attri buteGroup> 
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Tableau A-4 Groupe d'attributs 



<xsd: element name="item"> 
<xsd : compl exType> 
<xsd: sequence> 
<xsd : el ement name="productName" 

type="xsd: string"/> 
<xsd:element name="quantity"> 
<xsd:simpleType> 
<xsd: restriction base="xsd: positiveInteger"> 

<xsd : maxExcl usi ve val ue="100"/> 
</xsd: restriction> 
</xsd : si mpl eType> 
</xsd:element> 
<xsd: el ement name="USPrice" 

type="xsd : deci mal "/> 
<xsd:element ref="comment" minOccurs="0"/> 
<xsd: el ement name="shipDate" type="xsd:date"/> 
</xsd:sequence> 

<xsd:attributeGroup ref="ItemDelivery"/> 
</xsd : compl exType> 
</xsd:element> 



La mixite des modeles 



Tableau A-5 Modele mixte 



Moclele UML 


Classe heritant du type de donnees string 








<<Data Type>> 
ItemDelivery 




«Primitive type>> 

string 




+partNum:SKU 
+shipBy:shipBy 
+weightKg:Decimal 








\ 




/ 


j 






Item 




+productName:string 

+quantity:positivelnteger 

+shipDate:Date 

+USPrice:Decimal 
+partNum:5KU 
+shipBy:shipBy 
+weightKg:Decimal 
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Tableau A-5 Modele mixte 

Representation XML 

Modele de contenu mixte 

<xsd: element name="item"> 
<xsd:complexType mixed=true> 
<xsd:sequence> 
<xsd : el ement name="productName" 

type="xsd : stri ng"/> 
<xsd: el ement name="quantity"> 
<xsd : si mpl eType> 
<xsd: restriction base="xsd:positiveInteger"> 

<xsd : maxExcl usi ve val ue="100"/> 
</xsd : restri cti on> 
</xsd : si mpl eType> 
</xsd:element> 
<xsd:element name="USPrice" 

type="xsd: decimal "/> 
<xsd:element ref="comment" minOccurs="0"/> 
<xsd: el ement name="shipDate" type="xsd:date"/> 
</xsd:sequence> 

<xsd : attri buteGroup ref="ItemDel i very"/> 
</xsd : compl exType> 
</xsd:element> 



Dans un cas particulier d'heritage, le type de donnees herite est le type primitif 
string. C'est un cas limite du point de vue de la conformite du modele UML, meme 
s'il reste valide. II permet de representer les modeles de contenu mixte de 
XML Schema comme indique dans le tableau A-5. 

Comme pour d'autres correspondances entre modeles de classes et XML Schema, la 
solution proposee dans ce paragraphe pousse le modele UML dans ses retranche- 
ments. Voila une indication supplemental comme quoi il n'y a pas recouvrement un 
pour un du modele de classes UML et de XML Schema. 



Contrainte d'exclusion et groupe de choix 

UML dispose d'une contrainte standard, appelee {xor}, permettant de definir une 
exclusion entre deux associations. 

Les contraintes d'exclusion xor sont representees par un groupe de choix XML. 
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VOCABULAIRE Contrainte d'exclusion 

Une contrainte d'exclusion indique qu'un objet ne peut etre relie que par I'une ou I'autre des associa- 
tions referencees par la contrainte. Dans I'exemple du tableau A-6, un employe est soit un employe avec 
prime de parking, soit un employe avec place de parking ; ou, ce qui est equivalent, il a soit une prime de 
parking, soit une place de parking. 



Tableau A-6 Contrainte d'exclusion et groupe de choix 



Modele UML 


Contrainte d'exclusion 








prime parking 






prime allouee 




employe avec prime de parking A 0..1 


0..1 




Employe 


; 


{ xor } 










; 


place de parking 










employe avec parking V 0..1 

1 : 






place allouee 








Representation XML 


Groupe de choix XML 

<xs: element name="Employe"> 
<xs : compl exType> 
<xs:choice> 

<xs : el ement name="parki ngAl 1 oue" 

type="placeDeParking"/> 
<xs : el ement name="pri medeparki ngAl 1 ouee" 

type="primeDeParking"/> 
</xs:choice> 
</xs : compl exType> 
</xs:element> 



Contraintes de simultaneity et groupes simples 

Outre la contrainte standard {xor} de UML, il existe d'autres contraintes sur associa- 
tions qui font l'objet d'un large consensus, en particulier la contrainte de simultaneite. 
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Vocabulaire Contrainte de simultaneite 

Une contrainte de simultaneite indique que si un objet participe a I'une des associations de la contrainte, 
il participe alors egalement aux autres associations. Dans I'exemple suivant, si une commande est a fac- 
turer, elle est aussi a livrer, et reciproquement. 



Figure A-1 

Contrainte de simultaneite 




a facturer Lieu de paiement 


Lieu 


facturation 

{ Simultaneite } 




a livrer livraison Lieu de livraison 



II est tentant d'utiliser directement les groupes simples XML (<xsd:group>) pour 
exprimer les contraintes de simultaneite dans les schemas XML. Malheureusement, 
contrairement aux groupes de choix, les groupes simples doivent etre declares comme 
des elements globaux pour etre reutilises dans plusieurs autres elements XML. Tel 
n'est pas l'objectif de la contrainte de simultaneite qui vise seulement la presence 
simultanee d'associations et non pas leur reutilisation. 

En UML, la reutilisation s'exprime toujours a l'aide de relations de generalisation. II 
faut done revoir le schema de la figure A-1 en consequence : une nouvelle classe abs- 
traite indique la mise en facteur des associations facturation et livraison ; la con- 
trainte de simultaneite est conservee. Une representation XML possible de ce 
modele de classe est presentee dans le tableau A-7. 



Tableau A-7 Contrainte de simultaneite et groupe simple 



Modele UML 

Contrainte d'exclusion 



Livrable & Facturable 

{Abstract! 


a facturer Lieu de paiement 


Lieu 


facturation 

{ Simultaneite} 






a livrer livraison Lieu de livraison 



I 



Commande 
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Tableau A-7 Contrainte de simultaneity et groupe simple 

Representation XML 

Groupe XML 

<xs : schema el ementFormDef aul t="qual i f i ed" 
att ri buteFormDef aul t="unqual i fi ed" 
xml ns : xl =http://www.w3. org/1 999/xlink 
xml ns:xs=" http://www.w3 .org/2001/XMLSchema"> 
<xs: import 

names pace=http://www. w3.org/1999/xlink 
schemaLocation="xlink.xsd"/> 
<xs:complexType name="entityRef"> 

<xs:attribute ref="xl :type" fixed="simple"/> 
<xs: attribute ref="xl : href" use="requi red"/> 
</xs : compl exType> 

<xs: group name="LivrableFacturable"> 
<xs:sequence> 

<xs: element name="LieuLivraison" 

type="entityRef"/> 
<xs : el ement name=" Li eu Fact u rati on" 
type="entityRef"/> 
</xs:sequence> 
</xs:group> 

<xs: el ement name="Commande"> 
<xs:complexType> 

<xs: group ref="LivrableFacturable"/> 
</xs : compl exType> 
</xs:element> 
</xs:schema> 



II faut ici remarquer un nouveau cas ou il n'y a pas de correspondance claire et directe 
entre le modele de classes UML et XML Schema. Le tableau A-7 indique un choix 
particulier de transformation des relations de generalisation en XML, qui vient 
s'ajouter a celles exposees dans le chapitre 3. 

Certaines recommandations conseillent i'utilisation de stereotypes UML pour faire 
correspondre directement les concepts de XML Schema et ceux de UML. 



VOCABULAIRE Stereotypes UML 

Les stereotypes sont une technique de marquage des classes UML utilisee pour etendre le metamodele 
UML et I'adapter a un cas d'emploi specifique, par exemple XML Schema. 
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La figure A-2 montre l'exemple du stereotype « Schema group » utilise pour repre- 
senter un groupe XML a l'aide d'une classe UML specifique. Cependant, l'usage de 
tels stereotypes ne fait que singer les concepts XML dans les modeles de classes 
UML, sans apporter veritablement de valeur ajoutee. La classe Livrable & 
Facturable n'est pas a proprement parler une classe et ne fournit pas une aide a la 
decouverte des classes entites et des modules de donnees, ce qui est l'objectif premier 
d'un modele de conception UML, ainsi que nous l'avons expose au chapitre 3. 
L'usage des stereotypes pour representer les specificites de XML Schema tient plus 
de la recette de cuisine que de la veritable modelisation de donnees. 



Figure A-2 

Utilisation d'un stereotype 
pour representer un 
groupe XML 




0..1 



<<Schema group» 
Livrable & facturable O 



afacturer 



Lieu de paiement 



factu ration 



{Simultaneity } 



o 



a livrer livraison Lieu de livraison 



Lieu 



La question de l'ordre des elements 



Pour XML Schema, l'ordre des elements revet une grande importance et fait partie 
integrante de la validation de la conformite des documents XML par rapport a leurs 
schemas. Tel n'est pas le cas des modeles de classes UML. Si Ton peut bien specifier 
un ordre pour les attributs, les roles d'associations et les generalisations d'une classe, 
cet ordre ne change pas substantiellement la nature du modele de classe. 

Les elements XML correspondant a une classe UML proviennent soit d'attributs et 
de roles d'associations directement relies a cette classe, soit d'attributs et de roles 
d'associations issus des classes heritees par les relations de generalisation. II n'est 
done pas possible d'obtenir un ordre absolu des elements XML, mais seulement un 
ordre relatif : ordre des elements provenant de generalisations + ordre des elements 
provenant d'attributs + ordre des elements provenant de roles d'associations. 

La regie le plus souvent appliquee est la suivante : 
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• Les elements en provenance des classes heritees viennent en premier. lis sont eux- 
memes ordonnes en fonction des deux regies suivantes. 

• Les elements en provenance d'attribut de classe viennent en second, dans l'ordre 
des attributs de la classe. 

• Les elements en provenance de role d'associations viennent en troisieme, dans 
l'ordre des roles de la classe. 

Le tableau A- 8 offre une illustration de l'application de ces regies. 

Tableau A-8 Ordre des elements 
Modele UML 



classe sur-type 



+attributS1:string 
+attributS2:string 



~zy 



classe associee T 



+attributC1:string 
+attributC2:string 



classe 



proprieteX 



classe aAssociee X 



role2 proprieteA 


classe associee A 




* 



Representation XML 

<?xml version="1.0" encoding="UTF-8"?> 

<xs : schema el ementFormDef aul t="qual i f i ed" 

attri buteFormDef aul t="unqual i f i ed" xml ns : xs="http : //www. w3 .org/2001/ 

XMLSchema"> 

<xs: element name="Classe"> 
<xs : compl exType> 
<xs:sequence> 

<xs : el ement name="att ri butSl"/> 
<xs: element name="attributS2"/> 
RoleT"/> 
attri butCl"/> 
attri butC2"/> 
proprieteX"/> 
proprieteA"/> 



<xs: el ement name= 
<xs: el ement name= 
<xs: el ement name= 
<xs: el ement name= 
<xs: el ement name= 
</xs:sequence> 
</xs : compl exType> 
</xs:element> 
</xs:schema> 



B 



Ressources 



Textes normatifs 

Au travers des chapitres de ce livre, un certain nombre de normes, qu'elles soient 
Internationales du W3C ou sectorielles, ont ete mentionnees, voire utilisees a titre 
d'exemple. Nous en donnons la liste au tableau suivant, accompagnee d'informations 
complementaires, notamment des URL, qui permettront au lecteur d'approfondir ses 
connaissances. 

Tableau B-1 URL des recommandations et normes mentionnees dans cet ouvrage 



Norme ou 


Editeur 


URL de la version utilisee pour ce livre et commentaires eventuels 


recommandation 






S1000D v2.1 


AECMA(3) 


Specification en date du 29 fevrier 2004. 
http://www.s1 000d.org/ 


ATA 21 00 


ATA(4) 


Specifications ATA pour les AMM (Aircraft Maintenance Manuals) 

http://www.airlines.org/public/publications 

Version 3.3 (decembre 1 998) des specifications ATA et version 3.0 de 
Janvier 1999 de la DTD pour les AMM. 
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Tableau B-1 URL des recommandations et normes mentionnees dans cet ouvrage 



Norme ou Editeur URL de la version utilisee pour ce livre et commentaires eventuels 
recommandation 


BPEL 


OASIS(5) 


Langage de specification de processus executables propose a I'origine par 
IBM et Microsoft sous le nom de BPEL4WS : Business Process Execution Lan- 
guage for Web Service. BPEL est un modele decrivant un enchamement de 
taches, eventuellement realisees a I'aide de services web. 

BPEL est depuis sa version 1.1 du 5 mai 2003 sous la responsabilite de I'orga- 
nisation OASIS sous le nom de WSBPEL : Web Service Business Process Execu- 
tion Language 


BURNS 


DSTC(16) 


Basic URN Service resolution. 
http://archive.dstc.edu.au/rdu/TURNIP/burns.html 


DocBook DTD 
V4.2CR3 


OASIS(5) 


http://www.oasis-open.org/docbook/ 

Copyright 1992-2002 HaL Computer Systems, Inc. 

O'Reilly & Associates, Inc., ArborText, Inc., Fujitsu Software 
Corporation, Norman Walsh, Sun Microsystems, Inc., and the 
Organization for the Advancement of Structured Information Standards 

(OASIS). 

$ld: docbook.dtd,v 1.14 2002/05/28 1 6:56:23 nwalsh Exp $ 
Permission to use, copy, modify and distribute the DocBook DTD and 
its accompanying documentation for any purpose and without fee is 
hereby granted in perpetuity, provided that the above copyright 
notice and this paragraph appear in all copies. The copyright 
holders make no representation about the suitability of the DTD for 
any purpose. It is provided "as is" without expressed or implied 
warranty. 


DOM Requirements 


W3C(1) 


http://www.w3.org/TR/2000/WD-DOM-Requirements-20000412 

Version de travail du 1 2 avril 2000 devenue une note de travail le 
26 fevrier 2004. 


DSSSL 


ISO(6) 


Standard ISO 10179 : 1996, Document Style Semantics and Specification Lan- 
guage 


FpML 


ISDA(2) 


Financial Products Markup Language version 1 .0 : 

http://www.fpml.org/spec/2000/tr-fpml-arch-1-0-2000-09-25 

Financial Products Markup Language version 2.0 : 

http://www.fpml.org/spec/2002/tr-fpml-2-0-2002-05-01 

FpML est soumis a une licence publique d'utilisation, disponible a I'adresse 
http://www.fpml.org/documents/license 

Note technique sur la migration de XML a XML Schema : 

http://www.fpml.org/spec/2002/TBA 
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Tableau B-1 URL des recommandations et normes mentionnees dans cet ouvrage 



Norme ou Editeur URL de la version utilisee pour ce livre et commentaires eventuels 
recommandation 


HyTime 


IS0(6) 


Standard ISO 10744- Hypermedia Time based Structuring Language. 
Ch. Goldfarb, Eliot Kimber, Steve & Peter Newcomb 


J2008 


SAE(7) http://www.xmlxperts.com/sae.htm 


PURL 


0CLC(14) http:/purl.oclc.org/OCLC/PURL/SUMMARY 


RDF 


W3C(1) 


RDF Vocabulary Description Language 1.0 : RDF Schema : 

http://www.w3.org/TR/2002/WD-rdf-schema-20020430/ 

Version de travail du 30 avril 2002 

RDF Primer : 

http://www.w3.org/TR/2002/WD-rdf-primer-20020319/ 

Version de travail 1 9 mars 2002 

RDF Schema Specification 1.0 : 

http://www.w3.org/2001 /sw/RDFCore/Schema/2001 091 3/ 

Version de travail, September @@XX 2001 (date exacte non precisee) 

RDF/XML Syntax Specification (Revised) : 

http://www.w3.org/TR/2002/WD-rdf-syntax-grammar-20020325 

Version de travail du 25 mars 2002 

RDF Model and Syntax Specification : 

http://www.w3.0rg/TR/1 999/REC-rdf-syntax-1 9990222 

Recommandation du 22 fevrier 1999 

RDF Schema Specification 1.0 : 

http://www.w3.org/TR/2000/CR-rdf-schema-20000327 

Candidate Recommandation du 27 mars 2000 


Relax 


INSTAC(8) 


MURATA Makoto — Regular Language description for XML — 2001 
http://www.xml.gr.jp/relax/ 
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Tableau B-1 URL des recommandations et normes mentionnees dans cet ouvrage 



Norme ou Editeur URL de la version utilisee pour ce livre et commentaires eventuels 
recommandation 


Relax NG 


0ASIS(5) 


Version du 3 decembre 2001 

http://www.oasis-open.org/committees/relax-ng/ 
spec-20011203.html 

Editee par : James Clark et MURATA Makoto 

Copyright © The Organization for the Advancement of Structured 
Information Standards [OASIS] 2001 . All Rights Reserved. 
This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it or 
assist in its implementation may be prepared, copied, published and 
distributed, in whole or in part, without restriction of any kind, provided 
that the above copyright notice and this paragraph are included on all 
such copies and derivative works. However, this document itself may not 
be modified in any way, such as by removing the copyright notice or 
references to OASIS, except as needed for the purpose of developing 
OASIS specifications, in which case the procedures for copyrights 
defined in the OASIS Intellectual Property Rights document must be 
followed, or as required to translate it into languages other than English. 


RFC 822 


IETF(9) 


Standard de I'lETF de 1982 definissant le format des fichiers de courrier elec- 
tronique. 

http://www.ietf.org/rfc.html 


Schematron 


ASCC(10) 


« The Schematron Assertion Language 1 .5 » 

Specification du 1 er octobre 2002. 

Sites a consulter : 

http://www.ascc.net/xml/resource/schematron/schematron.html 

http://sourceforge.net/projects/schematron 


SGML 


ISO(6) 


ISO 879-986 (edition ) et ISO 8879:1979 (edition ). 


SOAP 


W3C(1) 


Recommandation depuis le 24 juin 2003. 
Version 1.1 : 

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ 
Version 1.2 PartO: Primer: 

http://www.w3.org/TR/2003/REC-soap12-part0-20030624/ 
Version 1 .2 Part 1 : Messaging Framework : 

http://www.w3.org/TR/2003/REC-soap1 2-part1 -20030624/ 
Version 1 .2 Part 2: Adjuncts : 
http://www.w3.org/TR/2003/REC-soap12-part2-20030624/ 
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Tableau B-1 URL des recommandations et normes mentionnees dans cet ouvrage 



Norme ou Editeur URL de la version utilisee pour ce livre et commentaires eventuels 
recommandation 


Topics Map 


ISO(6) 


ISO 13250:1998 

Michel Biezunski, Martin Bryan et Steve Newcomb 


TREX 


TOSSC(H) 2001 James Clark 

Tree Regular Expressions for XML 
http://www.thaiopensource.com/trex/ 


UBL 


0ASIS(5) 


Proposition de OASIS du 17 novembre 2003 visant a fournir un modele 
d'echange des documents relatifs aux transactions commerciales (comman- 
des, facturations...) 

http://www.oasis-open.org/committees/ubl/lcsc/UBLv1-beta 


UDDI version 2.0 


UDDI.org 
(12) 


Standard de UDDI.org initialement propose par Ariba, IBM, Microsoft 
(septembre 2000). La version Open Draft Specification 2.0 de juin 2001 a ete 
realisee par IBM, Microsoft et SAP. 

http://www.uddi.org/pubs/ 
DataStructure-V2.00-Open-20010608.pdf 

Copyright © 2001 by Accenture, Ariba, Inc., Commerce One, Inc., Compaq 
Computer Corporation, Equifax, Inc., Fujitsu Limited, Hewlett-Packard Com- 
pany, i2 Technologies, Inc., Intel Corporation, International Business Machi- 
nes Corporation, Microsoft Corporation, Oracle Corporation, SAP AG, Sun 
Microsystems, Inc., and Verisign, Inc. All Rights Reserved 

http://www.uddi.org/pubs/ 
DataStructure-V2.00-Open-20010608.pdf 

version 3 : 

http://uddi.org/pubs/uddi_v3.htm 


Infrastructure 
UML2.0 


0MG(13) 


Infrastructure de UML 2.0 

Le statut de la specification est : « Final Adopted Specification ». Un dernier 
vote du processus de publication de I'OMG devrait donner son statut officiel 
a la specification, totalement publique avant la fin de I'annee 2005. 

http://www.omg.org/cgi-bin/doc7ptc/2003-09-15 


Superstructure 
UML2.0 


0MG(13) 


Superstructure de UML 2.0 

Le statut de la specification est : « Final Adopted Specification ». Un dernier 
vote du processus de publication de I'OMG devrait donner son statut officiel 
a la specification, totalement publique avant la fin de I'annee 2005. 

http://www.omg.org/cgi-bin/doc7ptc/2004-10-02 
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Tableau B-1 URL des recommandations et normes mentionnees dans cet ouvrage 



Norme ou Editeur URL de la version utilisee pour ce livre et commentaires eventuels 
recommandation 


MOF2.0 


OMG(13) 


Meta Object facility version 2.0 

Le statut de la specification est : « Final Adopted Specification ». Un dernier 
vote du processus de publication de I'OMG devrait donner son statut officiel 
a la specification, totalement publique avant la fin de I'annee 2005. 

http://www.omg.org/cgi-bin/doc7ptc/2003-10-04 


URI 


IETF(9) 


RFC 2396 d'aout 1998. 
http://www.ietf.org/rfc.html 


URL 


IETF(9) 


RFC 1 738 dedecembre 1994. 
http://www.ietf.org/rfc.html 


URN 


IETF(9) 


RFC 2141 demai1997. 
http://www.ietf.org/rfc.html 


UUID 


ISO(6) 


ISO/IEC 11578:1996 

Calcul des identifiants uniques universels 


WebDAV 


IETF(9) 


RFC 251 8 de fevrier 1 999 et 3253 de mars 2002. 
http://www.ietf.org/rfc.html 


WSDL 


W3C(1) 


La specification 1 .0 du 25 septembre 2000 a donne lieu a une note du 
W3C 1 .1 le 1 5 mars 2001, editee par Microsoft et IBM. 

http://www.w3.org/TR/2001/NOTE-wsdl-20010315 

Les textes sont actuellement a I'etat de derniere version de travail depuis le 
3 aout 2004. 

http://www.w3.org/TR/2004/WD-wsdl20-20040803/ 

http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/ 

http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/ 


XMI2.0 


OMG(13) 


XML Metadata Interchange 2.0 

Format d'echange des modeles MOF-UML 

http://www.omg.org/cgi-bin/doc7formal/2003-05-02 


XML Canonical 


W3C(1) 


http://www.w3.org/TR/2001/REC-xml-c14n-20010315 
Recommandation du 15 mars 2001 


XML 


W3C(1) 


http://www.w3.org/TR/2000/WD-xml-2e-20000814 
Version de travail du 14 aout 2000 


XML Infoset 


W3C(1) 


http://www.w3.org/TR/2001/REC-xml-infoset-2001 1 024 
Recommandation du 24 octobre 2001 
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Tableau B-1 URL des recommandations et normes mentionnees dans cet ouvrage 



Norme ou Editeur URL de la version utilisee pour ce livre et commentaires eventuels 
recommandation 


XML Namespace 


W3C(1 ) Recommandation du 1 4 Janvier 1 999 

http://www.w3.Org/TR/1 999/REC-xml-names-1 99901 1 4 


XML Schema 


W3C(1) 


Vous trouverez les textes de la recommandation XML Schema aux adresses 

http://www.w3.org/TR/2001/REC-XMLschema-0-20010502/ 
http://www.w3.org/TR/2001/REC-XMLschema-1-20010502/ 
http://www.w3.org/TR/2001/REC-XMLschema-2-20010502/ 

pour les versions anglaises des tomes 0, 1 et II, et aux adresses 

http://XMLfr.org/w3c/TR/XMLschema-0/ 
http://XMLfr.org/w3c/TR/XMLschema-1 

pour les versions francaises des tomes et I. 


XPathl.O 


W3C(1) 


Recommandation du W3C du 16 novembre 1999 

Version francaise : 

http://xmlfr.org/w3c/TR/xpath/ 

Version anglaise : 

http://www.w3.0rg/TR/1 999/REC-xpath-1 9991 1 1 6 


XPath 2.0 


W3C(1) 


Version de travail du 30 avril 2002 
http://www.w3.org/TR/2002/WD-xpath20-20020430 


XSLv1.1 


W3C(1) 


Document de travail du 1 7 decembre 2003. 
http://www.w3.org/TR/2003/WD-xsl1 1 -20031 21 7/ 


XSL-fo 


W3C(1) 


Recommandation du 1 5 octobre 2001 definissant un vocabulaire XML pour le 
formatage des documents XML. 


XSLT 1 .0 


W3C(1) 


Recommandation du 1 6 novembre 1 999 definissant un langage XML pour 
programmer des operations de transformation de documents XML. XSLT est 
tres utilise pour transformer des donnees XML en donnees HTML affichees 
dans un navigateur, mais cela n'est pas la seule application possible. 

Version francaise : http://xmlfr.org/w3c/TR/xslt/ 

Version anglaise : http://www.w3.0rg/TR/1 999/REC-xslt-1 9991 1 1 6 


XSLTv2.0 


W3C(1) 


Version de travail du 1 2 novembre 2003 
http://www.w3.org/TR/xslt20/ 


XQuery 


W3C(1) 


XQuery n'est pas encore une recommandation (le dernier document de travail 
est date du 4 avril 2005). 

http://www.w3.org/TR/2005/WD-xquery-20050404/ 

XQuery est une transposition en XML du langage SQL qui vise a interroger 
des bases de donnees XML de la meme maniere que le SQL est utilise pour 
interroger les bases de donnees relationnelles. 
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Tableau B-1 URL des recommandations et normes mentionnees dans cet ouvrage 



Norme ou 
recommandation 

XUpdate 



Editeur URL de la version utilisee pour ce livre et commentaires eventuels 

Xmldb.org L'objet de Xupdate est de specifier en XML un langage de mise a jour des 
donnees stockees dans des bases de donnees XML. 

Le texte est a I'etat de document de travail depuis le 14 septembre 2000. 

http://xmldb-org.sourceforge.net/xupdate/xupdate-wd.html 

Le W3C a annonce que XUpdate serait une base de travail pour mettre au 
point un langage de mise a jour de documents XML mais qu'il ne pouvait etre 
integre a XQuery en I'etat (Jonathan Robie, 30 mai 2002). 



1 World Wide Web Consortium - Copyright© 1999 W3C (MIT, INRIA, Keio), 
All Rights Reserved. W3C liability, trademark, document use and software licen- 
sing rules apply 

2 International Swaps and Derivatives Association, Inc. 

3 Association europeenne des constructeurs de materiel aeronautique 

4 Air Transport Association 

5 Organization for the Advancement of Structured Information Standards 

6 International Standard Organization 

7 Society for Automotive Engineers 

8 Information Technology Research and Standardization Center 

9 Internet Engineering Task Force 

10 Academia Sinica Computing Centre 

1 1 Thai Open Source Software Center 

1 2 Universal Description Discovery & Integration Organization 

1 3 Object Management Group 

14 Online Library Computer Center 

1 5 Business Process Management Initiative 

1 6 Cooperative Research Centre for Distributed Systems Technology 
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Bibliographie 



Aux textes normatifs susmentionnes, il convient d'ajouter un certain nombre 
d'ouvrages et articles. 

A schema for serialized infosets, R. Tobin, H. Thompson, LTG, University of 
Edinburgh, http://www.w3.org/2001/05/serialized-infoset-schema.html 

UML, M. Fowler, CampusPress, ISBN 2-7440-1090-1, avril2001 

Modelisation d' applications XML avec UML, D. Carlson, Eyrolles, 
ISBN 2-212-09297-0, octobre 2001 

State of California, Air Resources Board, Final statement of reasons for rulemaking inclu- 
ding summary of comments and agency response, considered : december 12, 1996 
Agenda Item No : 96-10-2 

An XML version ofSAEJ2008, Version 1.01 XML, D. Kennedy, 3/3/99, 
http://www.xmlxperts.com/saexml.htm 

Storing XML in relational databases, I. Dayen, 20 juin 2001, 
http://www.xml.eom/pub/a/2001/06/20/databases.html 

XML and databases, R. Bourret, fevrier 2002, 
http://www.rpbourret.com/xml/ XMLAndDatabases.htm 

XML database products, R. Bourret, 14 mai 2002, 
http://www.rpbourret.com/xml/ProdsCMS.htm 

Mapping DTDs to databases, R. Bourret, 2000, 
http://www.xml.eom/lpt/a/2001/05/09/dtdtodbs.html 

Content model algebra, Exoterica Corporation, 
http://home.chello.no/~mgrsby/sgmlintr/file0003.htm 

XML Schema, E. van der Vlist, O'Reilly, ISBN 2-84177-215-2 

XML, A. Michard, Eyrolles, ISBN 2-212-09052-8 

Services Web avec SOAP, WSDL, UDDI, ebXML, J.-M. Chauvet, Eyrolles, 
ISBN 2-212-11047-2 

XML et les bases de donnees, K Williams, M. Brundage, R Dengler, J. Gabriel, 
A. Hoskinson, M. Kay, T. Maxwell, M. Ochoa, J. Papa, M. Vanmane, Eyrolles, 
ISBN 2-212-009282-2 

La theorie du chaos — Vers une nouvelle science, J. Gleick, traduction de C. Jeanmougin, 
Flammarion, ISBN 2-08-081219-X 

Introducing the Schematron, Uche Ogbuji, ITWorld, http://itworld.com 
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Bases de donnees : des systemes relationnels aux systemes a objets, CI. Delobel, 
Ch. Lecluse, Ph. Richard, InterEditions, sept. 1991 ISBN 2-7296-0371-9 

Schemas XML, J. -J. Thomasson, Eyrolles, ISBN 2-212-11195-9 

Services Web avecJ2EE et .NET, L. Maesano, Ch. Bernard, X. Le Galles, 
Eyrolles 2003, ISBN 2-212-11067-7 



c 



Sigles et acronymes 





AECMA Association Europeenne des Constructeurs de Materiel Aeronautique 


ASD 


AeroSpace and Defence Industries Association of Europe 


ATA 


Air Transport Association 


BPEL 


Business Process Execution Language. 


BPEL4WS Business Process Execution Language for Web Services. 


BPMI Business Process Management Initiative 


BPMN 


Business Process Modeling Notation 


BPQL 


Business Process Query Language 


BURNS 


Basic URN Service. 


DSTC 


Cooperative Research Centre for Distributed Systems Technology 


FPML Financial Product Markup Language 


IETF Internet Engineering Task Force 


ISDA 


International Swaps and Derivatives Association 


MOF 


Meta Object Facility 


NAICS 


North American Industry Classification System 


OCLC 


Online Computer Library Center 


OASIS 


Organization for the Advancement of Structured Information Standards 
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Sigles et acronymes Forme developpee 


OMG Object Management Group 


PURL 


Permanent URL 


RDF 


Resource Description Framework 


RDU 


Resource Description Unit 


SGML 


Standard Generalized Markup Language 


SOAP 


Simple Object Access Protocol 


TREX 


Tree Regular Expressions for XML 


UDDI 


Universal Description Discovery & Integration 


UBL 


Universal Business Language. 


UML 


Unified Modeling Language 


UNSPSC 


Universal Standard Products and Services Classification 


URI 


Uniform Resource Identifier 


URL 


Uniform Resource Locator 


URN 


Uniform Resource Names 


URC 


Uniform Resource Characteristic 


UUID 


Universally Unique ID 


W3C 


World Wide Web Consortium 


WAP 


Web Access Protocol 


WebDAV 


Distributed Authoring and Versioning Protocol for the World Wide Web 


WML 


Wireless Markup Language. 


WSBPEL 


Web Service Business Process Execution Language 


WSDL 


Web Services Description Language 


XMI 


XML Metadata Interchange 


XML 


Extended Markup Language 


XQuery 


XML Query language 


XSL 


extensible Stylesheet Language 


XSLT 


XSL Transformations 


XTM 


XML Topics Map 


XUpdate 


XML Update language 



D 



Infoset 



Vous trouverez ici une description detaillee du modele Infoset du W3C. Elle vient en 
complement de l'introduction faite a ce modele dans le chapitre 2. 



Unite d'information de type document 

L'unite d'information document est celle par laquelle commence le document XML. 
Souvent, elle est appelee prologue. 

Cette unite d'information a les proprietes suivantes : 

• Des enfants pouvant etre: une unite d'information de type element qui corres- 
pond a la racine du document XML, une instruction de traitement par instruc- 
tion de traitement se trouvant en dehors du contenu meme du document XML et 
de la DTD eventuellement presente en debut de document XML, une unite 
d'information de type declaration de type de document quand une telle declara- 
tion est presente dans le prologue du document XML. 

• Le cas echeant une propriete notations : constitute exactement d'une unite 
d'information de type notation par notation declaree dans la DTD. 

• Des entites non analysees : exactement une par entite non analysee declaree dans 
la DTD. 

• Un URI de base : celui de l'entite document. 
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• Un type de codage des caracteres : celui declare dans l'entite document (concrete- 
ment, le type de codage des caracteres est declare via la declaration XML sous la 
forme <?xml version="1.0" encoding="utf-8"?> par exemple). 

• Un indicateur de completude dont la valeur peut etre yes ou no. II indique si le 
document XML a deja ete analyse et canonise ou si des valeurs par defaut restent 
a decouvrir au travers de la DTD ou du schema. 

• Un attribut de version representant la version de XML utilisee dans le document. 

• Un indicateur de traitement des declarations d'entites qui ne fait pas partie vraiment 
du document mais que le parseur renseigne pour indiquer s'il a lu ou non la DTD. 



Unite (information de type element 

Les unites d'information de type element correspondent aux balises contenues dans un 
document XML. En particulier, 1' element racine est une unite d'information de type 
element qui fait l'objet d'une propriete de l'unite d'information de type document. 

Cette unite d'information a les proprietes suivantes : 

• Un espace de noms qui est renseigne quand i'element est rattache a un espace de 
noms specifique. 

• Un nom local qui est le nom de I'element diminue de l'eventuel prefixe represen- 
tant un espace de noms et du signe « deux-points » qui va avec. 

• Le cas echant un prefixe qui est celui associe a l'espace de noms. 

• Un ensemble d'enfants qui representent chacun l'une des unites d'information 
constitutives du corps du document XML. Ensemble ordonne selon leur ordre 
d'apparition dans le document. 

• Un ensemble d'unites d'information de type attribut, exactement une par attribut 
porte explicitement ou implicitement par I'element. 

• Un ensemble d'unites d'information de type attributs representant des declara- 
tions d'espaces de noms : exactement une par declaration d'espace de noms, y 
compris si un espace de noms par defaut est declare. 

• Une liste d'espaces de noms valides pour I'element courant. 

• LURI de base valable pour I'element. 

• Le parent de I'element courant. 
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Unite d'information de type attribut 



Les unites d'information de type attribut correspondent aux attributs portes par les 
elements. Elles sont utilisees pour tous les attributs, y compris ceux definis avec une 
valeur par defaut dans la DTD ainsi que 1' attribut special de declaration d'espace de 
noms. 

Cette unite d'information a les proprietes suivantes : 

• Le cas echant un nom d'espace de noms. 

• Un nom local. 

• Un prefixe. 

• Une valeur normalisee : il s'agit de la valeur de l'attribut suite a sa mise en forme 
lexicale conformement aux regies de normalisation edictees par XML ou les cata- 
logues de types de XML Schema. 

• Un indicateur permettant de savoir si l'attribut etait present des le depart dans le 
document XML ou s'il a ete ajoute par le parseur (ce qui arrive quand l'attribut a 
une valeur par defaut attribute par la DTD ou le schema XML). 

• Un indicateur du type de l'attribut. 

• Un indicateur de reference pour les attributs qui sont de type identificateur ou 
reference a une entite ou une notation. 

• Un indicateur permettant de connaitre 1' element proprietaire de l'attribut. 



Unite d'information de type instruction de traitement 

Ce type d'unite d'information correspond aux instructions de traitement presentes 
dans le document XML. 

II a les proprietes suivantes : 

• Une cible. 

• Un contenu. 

• UnURI debase. 

• Le cas echeant une notation correspondant au nom de la cible. 

• Un parent qui est l'unite d'information element de type document ou definition 
de type de document. 
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Unite (('information de type reference d'entite non 
resolue 

L'unite d'information de type reference d'entite non resolue est utilisee quand le pro- 
cesseur XML n'a pas expanse une entite externe. 

Cette unite d'information a les proprietes suivantes : 

• Le nom de I'entite referencee. 

• Le cas echeant l'identifiant systeme de I'entite. 

• Le cas echeant l'identifiant public de I'entite. 

• Le cas echeant l'URI de base de l'identifiant public. 

• L'unite d'information parent qui la contient. 



Unite d'information de type caractere 

II existe une unite d'information de type caractere par caractere de donnee du docu- 
ment, meme ceux qui apparaissent sous la forme de reference de caractere. 

Cette unite d'information a les proprietes suivantes : 

• Le code ISO 10646 du caractere. 

• Un booleen qui indique si un espace blanc valide fait partie du contenu du docu- 
ment ou non. 

• Un parent qui est une unite d'information de type element. 



Unite d'information de type commentaire 

II existe une unite d'information de type commentaire par commentaire present dans 
le document, a l'exception de ceux se trouvant dans la DTD du document. 

Cette unite d'information a les proprietes suivantes : 

• Un contenu constitue de la chaine de caracteres formant le commentaire a pro- 
prement parler. 

• Un parent qui est une unite d'information de type element ou document. 
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Unite d'information de type declaration de document 

L'unite d'information de type declaration de document existe quand le document XML 
a une declaration de type de document. Les eventuelles declarations d'entites et nota- 
tions definies dans la declaration de type de document sont des proprietes de l'unite 
d'information de type document et non de celle que nous sommes en train d'ecrire. 

Cette unite d'information a les proprietes suivantes : 

• Le cas echeant un identificateur systeme permettant de referencer l'eventuel corps 
de la DTD qui peut etre stocke dans un fichier a part. 

• Le cas echeant un identificateur public. 

• Des enfants composes des unites d'information de type instruction de traitement 
presentes dans la DTD. 

• L'unite d'information parent de type document. 



Unite d'information de type entite non analysee 

Une unite d'information de type entite non analysee existe pour chaque entite gene- 
rale declaree dans la DTD. 

Cette unite d'information a les proprietes suivantes : 

• Le nom de l'entite. 

• Le cas echeant un identificateur systeme. 

• Le cas echeant un identificateur public. 

• Le cas echeant l'URI de base de l'identificateur systeme. 

• Le cas echeant un nom de notation. 



Unite d'information de type notation 

Une unite d'information de type notation existe pour chaque notation definie dans 
la DTD. 

Cette unite d'information a les proprietes suivantes : 

• Un nom. 

• Le cas echeant un identificateur systeme. 

• Le cas echeant un identificateur public. 

• Le cas echeant l'URI de base de l'identificateur systeme. 
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Unite (('information de type espace de noms 

Chaque element du document a comme propriete une unite d'information de type 
espace de noms pour chaque espace de noms en vigueur au niveau de l'element. 

Cette unite d'information a les proprietes suivantes : 

• Le prefixe associe a l'espace de noms. 

• Le nom de l'espace de noms que ce prefixe represente. 
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Accessoire polymorphe 

Cette locution est relative au modele SOAP utilise dans les services web. Elle 
designe une maniere de transmettre, sous forme XML, des tableaux a n dimensions 
contenant un nombre variable de types de donnees. Ce mecanisme original n'est sup- 
ports naturellement ni par XML ni par XML Schema. 

Adressage 

On designe par adressage tout ce qui concourt a connaitre et exploiter le lieu de stoc- 
kage d'une donnee ou d'une ressource. Le plus souvent, il s'agit d'un chemin d'acces, 
mais cela peut prendre des formes plus sophistiquees en XML, par exemple avec 
Xpointer ; technique qui permet de combiner un chemin d'acces dans un systeme de 
fichiers avec un chemin d'acces a l'interieur d'un document XML. 

Agregation 

Terme issu du monde UML, une agregation est un type d'association entre deux 
classes exprimant un rapport entre un tout et ses parties. La classe formant le tout est 
appelee « agregat », l'autre classe designe les parties. Les agregations indiquent ainsi 
un rapport structurel entre les classes. 

Par exemple, on considerera une famine comme un tout et les membres de la famille 
comme les parties. 

Voir composition. 
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Ambiguite 

Lambiguite est l'incapacite a dire si un document XML est valide ou non. Le plus 
souvent, les validateurs, ou parseurs, pourraient lever l'ambiguite en allant voir plus 
en avant ce que le document XML contient ; cela s'appelle le lookahead, mais c'est 
interdit par l'ensemble des normes et recommandations SGML et XML. 

Les expressions « modeles ambigus » de SGML, « modele de contenu non 
deterministe » de XML 1.0 et « regie de la particule unique » designent le meme 
probleme d'ambiguite dont XML Schema donne la definition suivante : 

« Un modele de contenu doit etre forme de telle maniere que, pendant la validation- d'une 
sequence d'unites d'information de type element, la particule, contenue directement, indi- 
rectement ou implicitement, avec laquelle on essaie de-validerl'une apres I'autre chaque 
unite de la sequence, doit pouvoir etre identifiee sans avoir a examiner le contenu ou les 
attributs de chaque unite et sans avoir besoin defaire appel aux informations relatives aux 
autres unites du reste de la sequence. » 

Appel d'entite 

Cette locution appartient aux mondes SGML et XML. Un appel d'entite designe 
i'utilisation d'un nom d'entite dans un document XML. Par exemple, soit une entite 
a laquelle on donne le nom texte, alors l'appel d'entite correspondant sera la chaine 
de caractere &texte ; . 

<!D0CTYPE sample [ 

<! ENTITY texte "Ceci est un paragraphe utilisant un appel d'entite. "> 



]> 

<root> 

<p>&texte;</p> 

</root> 

Applicability 

Lapplicabilite est I'identification de l'objet auquel s' applique une information. La 
gestion de l'applicabilite peut prendre des formes simples, tel un simple nom de sys- 
teme, ou complexes lorsque ledit systeme possede des variantes techniques 
(« applicable pour les outils de la marque untel... »), temporelles (« applicable du tant 
ou tant... »), calendaires (« applicable a partir de telle date... ») et geographiques 
(« applicable aux systemes produits en Espagne... »). Ces criteres d'applicabilite peu- 
vent etre combines entre eux. 
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Arbre, arborescence 

Le concept de classification de l'information sous la forme d'arbre n'est pas nouveau. 
Tous les systemes mecaniques ou logiques sont tot ou tard, dans leurs phases de con- 
ception, decomposes en objets elementaires prenant la forme d'une arborescence. 

En XML, l'organisation arborescente de l'information est evidente, mais dans les 
representations UML des modeles de donnees, une telle representation arborescente 
n'est pas un postulat de base. En effet, une representation arborescente n'est suffi- 
sante ni pour representer la maniere dont les donnees interagissent les unes avec les 
autres, ni les liens entre ces memes donnees. 

Architecture 

Par analogie avec l'art de construire des edifices, l'architecture en informatique 
designe les principes et techniques d'organisation des systemes informatiques ; par 
exemple, l'architecture en trois tiers, l'architecture de service, etc. 

Articulation 

Par analogie avec le corps humain, l'articulation est un mecanisme qui donne de la 
souplesse a un modele : 

• Le modele peut integrer facilement d'autres modeles. 

• Le modele peut valider des documents XML de plus petite taille que le modele 
lui-meme. 

Attributs flottants 

Un attribut est dit flottant quand on peut le mettre n'importe ou dans la structure 
sans declaration prealable. Actuellement, XML Schema permet d'y recourir seule- 
ment pour les attributs de l'espace de noms XML Schema Instance, reconnu par le 
prefrxe xsi qui lui est souvent associe. Les trois attributs les plus connus de 
XML Schema Instance sont xsi:type, xsi :noNamespaceSchemaLocation et 
xsi :schemaLocation. Un autre attribut flottant connu est xmlns qui definit un pre- 
frxe d'espace de noms. 

Cela devrait egalement devenir le cas a terme avec les attributs de XLink. 

Backbone 

Encore appele structure d'assemblage ou squelette, un backbone est un document 
XML dont la seule vocation est de definir un assemblage (ordonne ou non) de 
documents XML. II s'agit done essentiellement d'un document XML qui contient 
des pointeurs vers d'autres documents XML. 
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Base de donnees 

Le nom complet en est Systeme de gestion de base de donnees, ou SGBD. Expression 
trop longue a dire et ecrire, l'habitude a ete prise d'utiliser la forme raccourcie base de 
donnees ; en revanche, le sigle SGBD est, quant a lui, reste. 

Tenant compte de ce contexte, une base de donnees est un logiciel capable de gerer 
un volume, en general important, de donnees. Gerer signifie ici : controler les 
imports et exports de donnees, l'acces aux donnees, leur mise a jour, leur coherence, 
et offrir des outils de calcul capables de s'appuyer sur la structure logique des donnees 
pour realiser des operations (calculs arithmetiques, booleens, recherche par motifs 
lexicaux ou valeurs. . .). 

Base de donnees XML 

II s'agit d'une base de donnees dediee au modele XML. Cela signifie que les donnees 
sont stockees dans des documents XML, que les fonctions d'extraction et de mise a 
jour sont celles definies pour les donnees XML (XQuery, Xupdate, DOM, XSLT, 
SAX), que les methodes d'acces sont compatibles avec un protocole tel que SOAP et 
que les standards definis par le W3C ou 1'ISO sont tout ou partie mis en oeuvre. 

II existe : 

• des bases « natives XML » developpees sur le seul modele XML ; 

• des bases relationnelles dans lesquelles le XML est projete (on dit « mappe »), ces 
bases etant restrictives car les modeles XML et relationnels ne sont pas egaux ; 

• des bases XML qui utilisent un moteur objet ; 

• des bases XML qui s'appuient sur des bases hierarchiques. 

Cardinality 

On appelle cardinalite le nombre d'elements d'un ensemble. En UML et XML, cela 
represente le nombre de fois qu'un objet peut etre utilise relativement a un autre. 

Carte ou cartographie de sujets, de topiques 

Expressions utilisees pour traduire les termes Topics Map. Elles designent un 
modele XML bien particulier dont la vocation est de definir les relations qui unissent 
des ressources informatiques, physiques ou virtuelles, ainsi que les descripteurs de ces 
dernieres. 

Cible 

Une cible est la ressource informatique, physique ou logique pointee par un lien, une 
relation ou tout mecanisme de referencement ou de liaison. 
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Classe 

Une classe est un ensemble concret ou logique qui contient tous les objets d'un meme 
type, voire d'un type derive ; on parle alors de classes et de sous-classes. 

La classe est concrete lorsqu'elle est definie une bonne fois pour toutes par pro- 
gramme, ou elle peut etre logique lorsqu'on fabrique, a la volee, des ensembles 
d'objets ayant des caracteristiques communes. 

Cle 

Dans une base de donnees, la meme information est parfois dupliquee ou croisee. La 
notion de cle est des lors un mecanisme permettant de connaitre la donnee de refe- 
rence et de faire la difference avec celles qui sont simplement des copies de cette 
donnee de reference. Une cle peut etre composee de plusieurs donnees qui, reunies, 
forment un identifiant unique d'une chose. Le mecanisme des cles existe tant pour 
les bases de donnees relationnelles que XML (on peut definir des cles avec 
XML Schema). 

Cle artificielle 

Cle ou element de cle n'etant pas une donnee propre de Implication mais un identi- 
fiant quelconque attribue de maniere mecanique a un ensemble de donnees. Par 
exemple, un simple numero incremental permet d'identifier les rangees d'un tableau, 
et ainsi de les differencier. 

Cle etrangere 

Une cle etrangere est tout simplement une information servant de cle ou partie de 
cle, mais reprenant la valeur d'une cle stockee ailleurs. Le principe des cles etrangeres 
existe egalement dans XML Schema. 

Composant ou constructeur 

Les composants sont les representations concretes des fonctions definies dans 
XML Schema : il s'agit des elements du vocabulaire de XML Schema utilises par un 
auteur qui ecrit un schema XML. Remarquez que le terme « composant » ne designe 
pas les attributs de ces elements mais seulement les elements. 

Composition 

Terme issu du monde UML, une composition est une association de type 
« agregation » ou l'existence des objets formant les parties est liee a celle de l'objet 
formant le tout. La suppression de l'objet parent - le tout - entraine celle des objets 
relies par l'association de composition - les parties. 
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Conceptuel 

On utilise le mot conceptuel dans les expressions modele conceptuel, modele conceptuel 
de donnees. II designe la representation ideale de la chose que Ton cherche a maitriser, 
l'idee que Ton cherche a transmettre, les donnees que Ton souhaite organiser, et les 
traitements et programmes qui feront les controles et manipulation des donnees. En 
informatique, le modele conceptuel des donnees est a un programme ce que le plan 
est a un immeuble. 

Controle lexical 

Le controle lexical consiste a verifier si les caracteres significatifs du langage XML 
sont utilises correctement. Par exemple, une valeur d'attribut s'ecrit entre deux 
guillemets droits " et non entre chevrons «. 

Controler que les caracteres utilises dans les chaines de caracteres des noms, valeurs 
et donnees du document XML sont conformes aux definitions lexicales de leurs 
types fait partie du controle lexical. Par exemple, un nom d'element doit commencer 
par une lettre, un souligne ou un deux-points, et tout autre caractere est interdit. 
Ainsi, des noms d'elements lexicalement valides sont para, _para et :para, et des 
exemples de noms invalides sont lpara, #para, etc. Vous pouvez remarquer qu'il est 
inutile de disposer d'un schema pour controler la validite lexicale de la syntaxe d'un 
document XML. En revanche, le schema est imperatif pour controler la validite lexi- 
cale des contenus d'elements et d'attributs. 

Controle grammatical 

Le controle grammatical porte sur la bonne utilisation du vocabulaire : dans l'ordre 
et a bon escient. 

On distingue deux niveaux de controle grammatical : 

• Lun consiste a controler que le schema est conforme au langage d'ecriture de 
schemas utilise. Par exemple, en XML Schema, le controle grammatical doit 
verifier qu'une definition d'element (constructeur xs: element) n'utilise pas simul- 
tanement les attributs name et ref. 

• Lautre consiste a controler que les elements et attributs d'un document XML res- 
pectent les regies definies par le schema dont depend le document XML. Par 
exemple, 1' element suivant un titre doit etre un para qui doit lui-meme etre 
qualifie par un attribut date. 

Controle syntaxique 

La syntaxe designe l'ensemble des caracteres et mots significatifs du langage. La 
racine grecque du mot syntaxe, suntaxis, veut dire « ranger ensemble » (sun, 



Glossaire 



ensemble, et tassein, ranger). La syntaxe est done la partie de la grammaire qui traite 
du role et de la disposition des mots et propositions dans une phrase. 

De meme qu'en francais, le point, la virgule et les autres signes de ponctuation jouent 
indeniablement un role dans 1' expression ecrite - ils sont remplaces par les intona- 
tions dans l'expression orale -, les documents XML et leurs schemas utilisent des 
caracteres significatifs qui leur sont propres. Cela se remarque immediatement en 
observant les extraits de ces langages representant une meme definition de modele : 

En XML 1.0: 

<!ELEMENT schema ((%inc"lude; | %import; | %redefine; | %annotation;)*, 
((%simpleType; | %complexType; | %element; | %attribute; | 
%attributeGroup; | %group; | %notation; ), 

(%annotation ;)*)* )> 
<!ATTLIST schema targetNamespace CDATA #IMPLIED > 

En XML Schema : 

<xs: element name="schema"> 
<xs : compl exType> 
<xs : compl exContent> 
<xs : extensi on base="xs : openAttrs"> 
<xs:sequence> 
<xs:cho"ice minOccurs="0" maxOccurs="unbounded"> 
<xs: element ref="xs:include"/> 
<xs: element ref="xs:import"/> 

</xs: choice> 

<xs: sequence mi nOccurs="0" maxOccurs="unbounded"> 
<xs: group ref="xs:schemaTop"/> 
<xs:element ref="xs:annotation" minOccurs="0" 
maxOccurs="unbounded"/> 
</xs:sequence> 
</xs:sequence> 
<xs: attribute name="targetNamespace" type="xs:anyURI"/> 

</xs : extensi on> 
</xs : compl exContent> 
</xs : compl exType> 

</xs:element> 

Les DTD comportent un grand nombre de caracteres syntaxiques que les schemas 
XML remplacent par du vocabulaire. Les caracteres significatifs des DTD, notam- 
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ment les connecteurs, tels que parentheses, virgules, barres verticales, etc. et les sym- 
boles d'occurrences (point d'interrogation, asterisque), sont remplaces dans les 
schemas par des noms d'elements. Ces changements resultent de la volonte d'utiliser 
dans XML Schema la syntaxe XML. Un schema s'ecrit comme n'importe quel docu- 
ment XML tandis qu'une DTD a son propre langage. 

Crochet 

Un element crochet est un element XML concu de telle sorte qu'il peut servir de 
point de raccordement d'un schema XML a un autre (voir aussi anneau). 

Data-module code 

C'est le code d'identification d'un module de donnees. Cette codification obeit a des 
regies strictes qui permettent de donner un sens metier a ce code. 

Derivation 

La derivation est une operation au moyen de laquelle on cree un type a partir d'un 
autre. II s'agit d'un terme utilise dans le monde des schemas XML. Comme des 
objets, les types derives les uns des autres forment un chainage qui possede ses pro- 
pres contraintes de fabrication et d'utilisation. 

Diagramme de classes 

Le diagramme de classes fait partie de la terminologie UML et designe la represen- 
tation graphique des classes d'un systeme de donnees et les relations (et cardinalites) 
qui les relient les unes aux autres. Le diagramme des classes est celui qui se rapproche 
le plus des besoins de representation des schemas XML. II n'est malheureusement 
pas parfait pour cet usage. 

Document electronique 

On appel document electronique tout objet informatique pouvant etre apparente a 
un document, au sens traditionnel du terme : un document papier, une photo, une 
video, une sequence sonore, peuvent etre des documents a partir du moment ou ils 
sont porteurs de sens. 

Linformatique offre desormais des zones d'ombre : un courrier electronique, un 
fichier PreAO (Presentation assistee par ordinateur), un objet multimedia, un fichier 
CAO (Conception assistee par ordinateur), un echange par messagerie instantanee, 
sont-ils des documents ? La reponse est affirmative si on considere que ces objets 
prennent du sens par rapport a un evenement particulier. Par exemple, on peut consi- 
derer que le courriel historique de John Bosak du 22 novembre 1996 a 14 h 06'58" 
annoncant la naissance de XML est un document. On peut egalement considerer 
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que tout fichier qui ne contient pas des donnees (au sens d'un alignement de valeurs 
atomiques) est un document. 

Document papier 

Un document papier a la caracteristique d'avoir une dimension physique finie : par 
exemple, une feuille de papier A4 et des contraintes de mise en page (les en-tetes et 
pieds de page par exemple). Aussi les deux caracteristiques principales d'un docu- 
ment papier sont-elles sa dimension et la typographic qui y est utilisee, parfois de 
maniere tres sophistiquee. 

Que le document soit papier, ou « papier electronique » comme PDF, ne change pas 
le probleme : pour que l'information soit comprehensible, claire et facile a lire, il faut 
quelle soit composee. Cela fait une grande difference avec les documents demateria- 
lises tels que des pages HTML pour lesquelles une qualite tres moyenne est souvent 
suffisante (on park ici du cas de l'information technique et non des pages HTML a 
caractere marketing ou le graphisme est souvent tres elabore). 

Document structure vs non structure 

Autrefois, tout document etait qualifie de « non structure '» par opposition aux don- 
nees, souvent stockees dans des tables, qui, de leur cote, etaient qualifiers de 
« structurees ». 

Avec XML, ce distinguo ha plus lieu d'etre : un document textuel est parfaitement 
structure. 

Document textuel vs donnees 

Une donnee est une valeur atomique qui n'a pas de sens en soi. Un tableau de chiffres 
(des dates par exemple) n'a jamais donne de sens a ces donnees. En revanche, il est 
possible de manipuler ces donnees (faire des calculs, des extractions, des tris, etc.). 

A l'oppose, un document est a priori un objet permettant de donner de la valeur aux 
donnees. Ce faisant, et avant que XML n'arrive, il n'etait plus possible de manipuler 
les donnees. 

Un document XML a des lors l'avantage de pouvoir contenir indifferemment des 
donnees et/ou des textes sur lesquels les manipulations et transformations sont tou- 
jours possibles. On est alors amene a parler de « donnees donnees » et « donnees 
textuelles ». 

Document XML 

Est baptise document XML tout fichier contenant des donnees balisees XML res- 
pectant les regies de bonne forme. Le mot document n'est done pas ici a prendre 
dans son sens commun. 
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Documentation modulaire structuree 

L'expression de documentation modulaire structuree designe une methode de con- 
ception de la structure d'un document (ou de tout autre objet) par laquelle des 
modules representent des composants textuels ou graphiques elementaires. Les 
modules contiennent des donnees balisees et ils sont assembles entre eux selon un 
ordonnancement logique, lui-meme defini au moyen d'un modele XML. 

DTD 

Le mot DTD est l'acronyme de deux choses differentes : d'une part definition de type 
de document et d'autre part declaration de type de document. 

Remarquez que, dans les deux cas, il faut dire « la » DTD et non « le » DTD comme 
on le voit trop souvent ecrit. 

La definition de type de document est le fichier qui contient des definitions d'ele- 
ments, d'attributs, d'entites et de notations. C'est en general ce fichier qui est 
designe quand on parle de « la DTD du document XML ». 

La declaration de type de document est la carte que Ton trouve dans le prologue d'un 
document XML et qui s'ecrit : <!DOCTYPE toto SYSTEM "toto.dtd">. Cette decla- 
ration specifie 1' element racine du document et lui associe la « DTD » qui convient. 

Effectivite 

Leffectivite complete les notions d'applicabilite. C'est une information qui indique 
le niveau d'obsolescence d'une autre information, en particulier d'une publication. 
Par exemple, un module d'information peut avoir une applicabilite aux systemes A, B 
et C, mais peut faire partie d'une publication dediee, quant a elle, au seul systeme B. 
Le uplet {A,B,C} represente l'applicabilite du module tandis que le singleton {B} 
represente l'effectivite de la publication. 

Element de donnees 

Un element de donnees ne contient que des donnees (numeriques ou textuelles peu 
importe) ou un modele qui peut etre assimile a de la donnee (cas d'un element mixte 
par exemple). 

Element de donnees global 

Un element de donnees global contient une collection d'elements de donnees, poten- 
tiellement meles a des donnees textuelles, voire des elements purement structurels. 
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Element flottant 

Un element est dit flottant quand on peut le mettre n'importe ou dans une structure. 
C'etait possible avec SGML grace au mecanisme des exceptions ; cela ne Test plus 
avec la version actuelle de XML. Le mouvement s'inversera peut-etre un jour. 

Element global 

II s'agit d'une terminologie XML Schema qui designe la qualite d'un element a etre 
utilise comme element racine d'un document XML et, par reference, dans plusieurs 
autres elements XML (voir egalement element local ci-apres). 

Element local 

II s'agit d'une terminologie XML Schema designant un element qui ne peut etre uti- 
lise ni comme racine d'un document XML ni par reference a l'interieur de plusieurs 
autres elements. Un element XML local n'appartient qua un seul element XML 
parent (voir egalement element global ci-avant). 

Element mixte 

Un element mixte contient, sur le meme niveau hierarchique, un contenu textuel et 
des sous-elements. Un tel element est typique de documents XML representant des 
documents papier. 

Element purement structurel 

Un element purement structurel ne contient aucun element de donnees comme 
enfant direct. 

Element racine 

Un element racine est le premier element d'un document XML. Un fichier renfer- 
mant un document XML ne peut contenir qu'un seul element racine. 

Ensemble d'informations 

Un ensemble d'informations est tout simplement un document XML. Cette locu- 
tion, qui est la traduction de 1' anglais infoset, est en train de rentrer dans le vocabu- 
laire courant de XML et permet avantageusement d'eviter d'utiliser le mot document, 
parfois trop proche des notions de document papier. 

Ensemble d'informations bien forme 

Un ensemble d'informations bien forme, ou well-formed infoset, est un ensemble 
d'informations qui verifie les criteres de bonne forme de XML. 
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Entite 

Dans le vocabulaire de XML, une entite est une ressource informatique que Ton peut 
specifier a l'aide d'une declaration d'entite. Une entite est typiquement soit une 
chaine de caracteres, soit un fichier XML, ASCII ou binaire. 

Espaces de noms, espaces de nommage 

Les espaces de noms, ou encore de nommage, servent a definir les limites de validite 
des vocabulaires definis par les schemas XML. Ainsi, une meme balise <prix> peut 
avoir deux significations differentes selon quelle appartient a un espace de noms A 
ou B, et on ecrira pour les distinguer <a:prix> et <b:prix>. 

Feuille 

Une feuille est un element terminal d'une arborescence de donnees XML, ou arbre 
XML. A ne pas confondre avec une feuille de papier ! 

Forme 

La forme est Failure que prend un ensemble de donnees lorsqu'il est ecrit en utilisant 
une syntaxe particuliere. La forme XML se reconnait aisement grace a ses balises et 
attributs emboites les uns dans les autres. 

Forme canonique 

La forme canonique d'un document XML enleve les ambiguites resultant des diffe- 
rentes formes lexicales que peut avoir un document XML, et ce afin de pouvoir sim- 
plifier les applications de traitement des documents XML et meme comparer de tels 
documents deux a deux. Les parseurs et les validateurs sont censes etre capables de 
produire les formes canoniques des documents qu'on leur soumet. 

Void les caracteristiques d'une forme canonique : 

• utilisation du seul codage UTF-8 ; 

• normalisation des valeurs d'attributs et repositionnement des attributs dans 
l'ordre alphabetique de l'initiale de leur nom ; 

• suppression du prologue du document ; 

• changement de notation des elements vides, ecriture de <gi ></gi > au lieu de <gi /> ; 

• integration des sous-documents : les appels d'entites externes analysees sont rem- 
places par les entites designees ; 

• homogeneisation des declarations de prefixes d'espaces de noms ; 

• suppression des prefixes d'espaces de noms des elements et attributs ou ils sont 
inutiles ; 

• inclusion des attributs par defaut. 
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Toutes les questions relatives a la canonisation ne sont pas reglees et ce sujet reste en 
discussion. 

Forme lexicale et forme lexicale canonique 

La forme lexicale est celle que Ton peut voir en consultant un document XML avec 
un editeur ASCII, done tel qu'il est enregistre sur disque, sans interpretation aucune 
des balises. La forme lexicale du chiffre 3 peut etre "03.00" ou "3" ou " 3 ", cela ne 
change pas la valeur numerique de ce contenu. XML Schema specifie des formes 
lexicales canoniques pour chaque type (dates, durees, nombres entiers, flottants, 
chaines de caracteres, etc.). 

Gestion de configuration 

La gestion de configuration consiste a gerer la version de chaque composant entrant 
dans la conception d'un systeme. Dans le cas de publications, il s'agit d'identifier 
chaque objet entrant dans la composition du document, qu'il s'agisse d'elements tex- 
tuels ou graphiques. 

Gestion de contenu 

Cela concerne la gestion des composants entrant dans la composition des pages web. 
Un outil de gestion de contenu permet de modeliser les pages d'un site web, produire 
les contenus textuels, gerer les liens entre les pages et avec les illustrations, et surtout 
les regies d'affichage en fonction de profils d'utilisateurs ou d'evenements autres. 

Gestion de I'applicabilite 

Voir applicabilite. 

Gestion de versions 

Cela consiste a gerer des variantes d'une version de base. Cela peut se faire par 
recopie des fichiers ou par modification a l'interieur du document XML. Un systeme 
doit permettre de conserver l'historique des liens avec le fichier d'origine, et even- 
tuellement de provoquer des alertes quand le fichier d'origine est modifie. 

Gestion des revisions 

La gestion des revisions consiste a stocker l'historique des fichiers. La gestion des 
revisions comprend toujours deux dimensions : d'une part une gestion des editions 
(un numero s'incremente a chaque fois qu'une modification mineure est effectuee) et 
d'autre part la gestion des revisions (apres une serie d'editions, une version finale est 
creee qui consolide toutes les editions). 



Modelisation XML 

Annexes 

Gestion des connaissances 

La gestion des connaissances (Knowledge Management en anglais) consiste a gerer des 
documents, des informations sur ces documents et une partie de l'activite qui accom- 
pagne un domaine particulier. Ainsi, si des forums de discussion sont ouverts sur des 
themes particuliers, il est interessant d'archiver les propos echanges pour les retrouver 
un jour, et parfois meme tres longtemps apres. Les savoir-faire, associes a des profils 
d'utilisateurs, sont ranges dans des classeurs thematiques virtuels auxquels on accede 
de plusieurs manieres. 

Gestion electronique de documents 

La gestion electronique des documents concerne les systemes dedies au controle des 
cycles de production des documents. Plus largement, la GED concerne tout systeme 
destine a controler un referentiel de documents. Pour cela, les documents sont 
accompagnes de metadonnees qui servent a les classer, les identifier, et fournir un 
resume ou des mots-cles relatifs a leur contenu. 

Grammaire 

Une grammaire est constitute des regies de positionnement des noms d'elements et 
d'attributs les uns par rapport aux autres. Un schema XML definit un vocabulaire 
(ensemble des noms des elements et d'attributs) et une grammaire. 

Comme dans une langue naturelle, en XML la grammaire sert a definir la logique 
d'assemblage des mots. Chaque schema definit une logique d'assemblage des ele- 
ments et des attributs. 

Heritage 

Lheritage est un concept qui vient du monde des objets. Ces derniers font partie de 
classes qui sont toujours creees a partir de classes parents. Ainsi, les proprietes et 
methodes d'une classe sont pour partie heritees de celles de leurs parents. 

Heritage et derivation 

Quand on veut modifier les caracteristiques, ou les methodes, heritees d'une classe 
parent, on opere ce qui s'appelle une derivation. 

Identifiant, identificateur 

Lidentifiant d'un element est ce qui permet de i'identifier de maniere unique : il 
s'agit d'une cle simple composee d'une seule chaine de caracteres. Avec XML 1.0, le 
seul type d'identifiant autorise etait le type ID. XML Schema permet de definir, 
quant a lui, de vraies cles qui sont des up! ets prenant la forme {A , B , C...} (voir le mot 
cle dans ce glossaire). 
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Infrastructure UML 2.0 

II s'agit du premier livre de la specification UML 2.0. II definit les principes fonda- 
teurs servant de base a la creation de tous les modeles de UML 2.0. 

Voir superstructure UML 2.0. 

Illustration code number 

Comme le code d'identification des modules (voir data-module code), celui destine 
aux illustrations est un identificateur unique pour une application metier. A la diffe- 
rence d'un module, ce code ne peut pas etre inscrit dans le fichier lui-meme et doit 
obligatoirement correspondre a un nom de fichier ; il ne peut done s'agir que d'une 
chaine de caracteres. 

Infoset 

Un infoset, litteralement ensemble d'informations, fait l'objet de la recommandation 
du W3C XML Infoset datee du 24 octobre2001. II s'agit de la nouvelle termino- 
logie utilisee pour designer un document XML. Cette recommandation a un role 
tres important. Grace a elle, les specifications du modele de documents XML et des 
schemas qui servent a les controler sont, pour la premiere fois, radicalement separees. 
En effet, la norme ISO 8879 (SGML) et la recommandation XML 1.0 du W3C 
melaient, jusqu'alors, la definition du modele de document XML et celle du langage 
d'ecriture de leurs schemas : les DTD. 

XML Infoset ne definit aucun langage d'ecriture de schema. Cette recommandation 
specifie qu'un document XML est un ensemble d'informations compose d'unites 
d'information et de contenus textuels. 

Nous avons choisi dans cet ouvrage de ne pas utiliser les expressions infoset et 
ensemble d'information, mais celle de document XML. 

Si Ton sait habituellement qu'un document XML est compose des unites d'informa- 
tion de type element et attribut, on sait moins en revanche qu'il peut contenir jusqu'a 
neuf autres types d'unites d'information, soit onze au total. Lobjectif de 
XML Infoset est de donner une definition precise de chacun d'eux. 

Ces onze types d'unites d'information sont les suivants : 

• la declaration de type de document ; 

• le document, e'est-a-dire l'element racine du document XML ; 

• l'element ; 

• l'attribut ; 

• l'espace de noms ; 

• l'instruction de traitement ; 
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• le commentaire ; 

• la reference a une entire externe ; 

• l'entite externe ; 

• le caractere ; 

• la notation. 

Les logiciels et textes normatifs qui se disent conformes a XML Infoset doivent 
prendre en charge la totalite de ces onze types d'unites d'information. 

Les langages d'ecriture de schemas de documents XML ne concernent qu'une partie 
de ces unites d'information : celles qui font la structure et le vocabulaire d'un docu- 
ment XML - les elements, les attributs, les espaces de noms, et dans une moindre 
mesure les notations. 

Sur le seul point de vue logique, referencer les entites externes utilisees par un docu- 
ment XML a partir de son prologue, c'est-a-dire dans un complement a la DTD, est 
une anomalie de conception de ces langages que les nouvelles approches, 
XML Schema et RelaxNG, corrigent avec XLink et XInclude. 

A contrario, des informations definies dans les schemas n'apparaissent pas en tant 
qu'unites d'information dans XML Infoset. II s'agit par exemple des types de don- 
nees. Le fait qu'une chaine de caracteres soit un nombre entier, une date ou une 
forme lexicale particuliere n'est pas une information censee etre contenue dans le 
document XML lui-meme. 

Ainsi, il est aujourd'hui flagrant qu'un document XML et son schema sont deux 
sources d'information independantes et complementaires. 

Voila pourquoi le concept de PSVI, Post Schema Validation Infoset, a ete invente. II 
s'agit d'un document XML qui contient l'infoset de depart, canonise et augmente 
des informations issues de son schema. Ainsi, le PSVI contient les informations sur 
le type des donnees, les modeles auxquels appartiennent les elements, la nature des 
attributs (impose, obligatoire, par defaut. ..). Le PSVI peut etre considere comme 
une sorte de fichier XML exporte dans lequel on aurait a la fois le document XML 
d'origine et la totalite des informations issues de son schema et le concernant. Le 
PSVI est un cas particulier d'ensemble d'informations. 

Instance 

Une instance est un objet cree a partir d'un modele et conforme a ce dernier. Dans le 
cas de SGML, les instances sont les documents SGML conformes a une DTD mais, 
en XML, le mot instance a disparu au profit des expressions document XML valide et 
ensemble d'informations XML valide. En ce qui concerne UML, et le monde des 
objets plus generalement, l'instance (d'une classe) est un objet qui possede les com- 
portements de la classe a laquelle il appartient. Cet objet est alors le composant 
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effectif des programmes (c'est lui qui calorie) alors que la classe est plutot une defini- 
tion ou une specification de l'ensemble des instances a venir. 

A notre grand etonnement, nous avons appris que ce mot a ete refuse a plusieurs 
reprises par l'Academie francaise, malgre son usage repandu parmi les informaticiens 
et sa presence dans le grand dictionnaire terminologique quebecois de la langue fran- 
caise (http://www.olf.gouv.qc.ca/ressources/gdt.html). 

Langage de liaison 

Un langage de liaison sert a ecrire (etablir) des liens ; il s'agit typiquement de XLink. 

Lien entre documents vs intra-document 

Un lien entre documents part d'un document XML pour aller dans un autre tandis 
qu'un lien intra-document reste limite au document XML ou se trouve la source du 
lien. Dans ce deuxieme cas, un simple identifiant suffit, tandis que dans le premier il 
faut ajouter, au minimum, le chemin d'acces du deuxieme document. On notera 
enfin que dans le cas du lien entre documents, le document dans lequel se trouve la 
cible du lien devient subordonne au premier : on ne peut le deplacer sans intervenir 
sur celui ou se trouve la source. 

Liste des pages effectives 

Une liste effective des pages est, en quelque sorte, une table des matieres des pages 
d'une publication. Concept reserve aux documents techniques sensibles, la liste 
effective des pages permet de lister chaque page de l'ouvrage avec, en regard, son 
indice de revision et son statut (effective ou detruite). Une telle liste est l'un des 
moyens de controle des revisions d'une publication. 

Metadonnees 

Une metadonnee est une donnee sur une donnee : par exemple, specifier que le 
nombre 1590575118235 est un numero de securite sociale necessite de faire appel a 
une metadonnee (en l'occurrence celle qui precisera le type de ce nombre). Dans le 
monde des documents, les metadonnees sont toutes les informations necessaires a la 
gestion administrative dudit document (numero ISBN, noms des auteurs, dates de 
parution, etc.). 

Metalangage 

Un metalangage est un langage qui sert a ecrire d'autres langages. Si on considere 
que le vocabulaire (noms des elements, des attributs et de leurs valeurs possibles) 
defini par une DTD ou un schema XML est un langage, alors le langage utilise pour 
ecrire de tels modeles est un metalangage. La syntaxe des DTD pouvant etre modi- 
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fiee, SGML les definissait a l'aide d'une syntaxe abstraite ; on avait vraiment la un 
metalangage. 

Metamodele 

Un metamodele est le pere d'un modele, on dit aussi le modele d'un modele. Le 
terme de meta fait reference au niveau d'abstraction supplemental induit naturelle- 
ment par la position de « pere de modele ». Pour XML, il existe deux branches 
parentes : celle de la syntaxe et celle des schemas. 

Dans la branche de la syntaxe, le modele pere d'un document XML est celui qui 
definit la syntaxe concrete d'ecriture des documents XML (en l'occurrence la recom- 
mandation Infoset), tandis que le metamodele (le grand-pere) est celui qui definit les 
relations parent-enfant, le fait que les elements aient des proprietes (les attributs), la 
notion de prologue, etc. Ce metamodele est visible dans la norme SGML 
ISO 8879:1986. 

Dans la branche des schemas, il existe plusieurs modeles peres (XML Schema, 
RelaxNG et Schematron) et plusieurs metamodeles qui sont les modeles conceptuels 
ayant servi a definir les vocabulaires (et les semantiques associees) de chacun de ces 
langages de modelisation. XML Schema et RelaxNG ont le meme metamodele : 
celui des langages a base de grammaire. Schematron est le resultat d'un metamodele 
different : celui des langages a base de regies. 

En valeur absolue, tout modele servant a produire d'autres modeles est un metamodele. 

Modele 

Le mot modele a deux sens. II peut designer le moule qui permet de reproduire a 
l'identique une meme chose comme il peut designer une representation simplifiee 
d'un ensemble de choses. Par exemple : un cylindre marron, des racines, une boule 
verte et des points rouges a l'interieur representent tous les pommiers de la terre ; un 
cercle jaune et des rayons : c'est le soleil. 

Modele et schema conceptuels 

II existe deux types de modeles conceptuels. Lun concerne les langages d'ecriture de 
schemas, 1' autre les donnees. 

En ce qui concerne les langages, un modele conceptuel est la definition theorique du 
langage, soit le prealable necessaire a la definition d'une forme concrete du langage. 
Un langage - par exemple le langage d'ecriture de schemas XML du W3C - doit 
etre defini de maniere theorique avant d'exister sous une forme concrete, ou syn- 
taxique. XML Schema est defini d'une part par des regies de production et d'autre 
part par des explications en langage naturel. Quant a lui, RelaxNG est formellement 
defini par des formules mathematiques dites regies d'inference. 
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En ce qui concerne les donnees, un modele conceptuel permet de les representer 
ainsi que les relations qui les unissent independamment de la maniere selon laquelle 
elles seront physiquement organisees, et notamment stockees. Un schema conceptuel 
est des lors une application d'un modele conceptuel de donnees pour une application 
particuliere. UML propose un modele conceptuel de representation des donnees. Un 
diagramme de classes UML realise pour une application particuliere representera le 
schema conceptuel des donnees de cette application. 

Modele logique 

Un modele logique represente la maniere selon laquelle les donnees seront reellement 
mises en oeuvre pour une application. Un schema XML, une DTD, sont des modeles 
logiques : ils representent la maniere dont seront reellement organisees les donnees, 
et notamment la maniere dont elles seront stockees les unes par rapport aux autres. 

Par exemple, on peut avoir un modele conceptuel representant des families compo- 
sees de parents et d'enfants : la presence d'une relation parent-enfant est de facto evi- 
dente. Ce modele conceptuel ne signifie pas pour autant que les elements XML cor- 
respondants seront <famine>, <pere>, <mere>, <fille> et <fils>, et que ces 
derniers seront des enfants des elements <pere> et <mere>. Le modele logique retenu 
in fine pour representer les families pourra etre totalement different des sous- 
entendus du modele conceptuel. On pourrait meme tres bien avoir des elements 
<individus> et <relation> permettant de lier les individus entre eux selon une 
logique de relations familiales. 

Modele vs schema, langage de modelisation 

Rickjelliffe, auteur de la specification Schematron, fait une distinction entre les 
termes « schemas » et « modeles ». Selon lui, un schema definit de maniere exhaus- 
tive et complete une realite tandis qu'un modele n'en est que la meilleure representa- 
tion possible. 

Nous soutenons cette approche que nous expliquons par une analogie : quand un 
homme sert de modele aux autres, il est un point de repere, un guide, un exemple a 
suivre, mais quand on affirme suivre le schema de pensee d'une personne, c'est qu'on 
deroule a l'identique un meme scenario intellectuel. De meme que le sculpteur dis- 
pose d'un modele et d'une technique pour realiser son oeuvre, les modeles et les 
schemas sont deux notions necessaires et complementaires pour produire un 
document XML. 

Dans le domaine technique, on peut dire d'une voiture quelle est de type break 
quand on peut la comparer a un objet de reference qui a ce type : un autre break 
montre en exemple. Cet objet de reference est le modele qui nous sert a reconnaitre 



Modelisation XML 

Annexes 

le type d'une autre voiture. La definition exacte de chaque voiture est cependant 
constitute des dessins techniques qui ont servi a la fabriquer : les plans, ou schemas. 

Le mot schema est done a prendre dans le sens que lui donnent les Americains, celui 
de plan tres precis d'un objet. Nous avons suivi ce distinguo dans cet ouvrage et avons 
choisi d'utiliser la terminologie suivante : 

• Le mot schema est utilise pour designer l'ensemble des regies definissant une 
classe de document. Un schema est typiquement une DTD ou un fichier conte- 
nant un document XML Schema ou RelaxNG. 

• Le mot modele designe la chose, ou l'idee, que Ton veut representer. Cela est tres 
different du schema. II en est ainsi des idees ayant prevalu a la definition concrete 
des schemas et des documents XML. En effet, tout document XML peut avoir 
un modele, a savoir un document XML exemple montrant ce qu'est la syntaxe 
XML et mettant en scene des elements, des attributs et d'autres unites d'informa- 
tions. Toutefois, seul un schema permettra de savoir si un document XML en 
particulier est bon ou pas pour une application specifique. 

II existe toutefois des exceptions « historiques », telle l'expression « modele de 
contenu d'un element » qui designe, dans une DTD, la definition d'un element. 
Dans un schema XML, le vocabulaire est plus precis, et on preferera parler du 
type de 1' element. 

• L'expression langage de modelisation n'est pas utilisee ; nous lui preferons langage 
d'ecriture de schemas. De la meme maniere, l'expression langage de schematisation 
n'est pas utilisee : elle choque sans correspondre a la realite qu'on voudrait lui 
donner. En ce qui concerne les modeles, nous ne parlerons que de representation 
des modeles. 

• Le mot metamodele est utilise pour designer le modele du modele, il designe bien 
souvent les concepts purement intellectuels ayant prevalu a la definition d'un 
modele. II existe par exemple un metamodele pour XML qui est constitue du 
concept d'objet (les types), de proprietes (les attributs) et d'heritage (les relations 
parent-enfant creees par les emboitements des elements forment des lignees 
d'heritages semantiques park seuljeu des noms d'elements). 

Module 

Dans le present ouvrage, un module est un document XML destine a faire partie 
d'un ensemble plus vaste. Le module n'a pas de taille predefinie, il peut s'agir d'un 
paragraphe comme d'un chapitre entier : e'est son auteur qui la determine. Un 
module est gere a l'aide de metadonnees. 

Noeud 

Un noeud est, dans un arbre representant une structure XML, un embranchement. 
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Objet metier 

Dans cet ouvrage, un objet metier est un element XML dont le nom est directement 
interprete par les programmes de traitement de l'information. Par exemple, si 1' element 
<dateDeVal eur> est un objet metier, il sera associe a un programme de meme nom. 

Occurrence et nombre (('occurrences 

L'occurrence est la repetition d'une meme chose. Aussi, le nombre d' occurrences est le 
nombre de fois qu'une chose apparait. En XML, la notion d'occurrence intervient 
dans les modeles (DTD et schemas) car c'est la que le concepteur precise combien de 
fois un element est autorise ; on parle alors du nombre d' occurrences. En UML, ce 
nombre d' occurrences est represente par la multiplicity. 

Ontologie et thesaurus 

Le dictionnaire Larousse donne de ces mots les definitions suivantes : 

Ontologie : (gr. On, ontos, etre, et logos, science). Discours issu de la logique mathema- 
tique et de la linguistique, qui traite des termes utilises pour designer les etres consti- 
tutifs de la realite. 

Thesaurus : (gr. Thesauros, tresor). Dictionnaire destine a aider les recherches dans 
certaines disciplines et contenant, pour chaque mot-cle, les termes similaires ou 
synonymes. 

Une ontologie est un dictionnaire de mots doubles de definitions de relations entre 
eux. A la difference d'un dictionnaire normal dont le seul sens de lecture est le sens 
alphabetique, les relations permettent a une ontologie d'avoir plusieurs sens de lecture. 

De son cote, un thesaurus est comparable a une ontologie reduite a un seul domaine 
et un seul type de relation entre les mots : la relation (hierarchique) d'appartenance a 
un domaine. Un thesaurus est done un dictionnaire augmente d'une seule structure 
additionnelle : une classification hierarchique des mots par domaine. 

Parseur (voir validateur) 

PSVI (voir la section Infoset) 

Persistance 

La persistance s' applique aux donnees qui doivent etre stockees pour « persister » au- 
dela du temps d'execution d'un programme. Dans les applications non standardises, 
la persistance pose simultanement le probleme du format de stockage des donnees 
(des champs de fichiers ASCII separes par des tabulations ? des champs de base de 
donnees ?, etc.) et de leur lieu de stockage. Cependant, avec XML, la question du 
format de stockage ne se pose plus (car les normes relatives a XML sont tees precises 
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sur la question). Ne subsiste que la question du lieu de stockage du document XML 
(dans des arborescences de fichiers, au sein d'une base de donnees XML, etc.), et 
eventuellement du vocabulaire qui sera utilise. 

Polymorphe 

Litteralement, se dit d'un objet qui presente plusieurs formes. Dans le monde XML, 
un objet est dit polymorphe lorsque le sens de la donnee qu'il contient depend du 
contexte dans lequel l'objet est baigne. Par exemple, le fragment 
<date>2004-08-27</date> prend un sens different selon que l'element parent est 
<Paiement> ou <Facturation>, par exemple. Aussi, dans la conception de schemas 
XML, le choix des noms attribues aux elements XML peut ne pas etre anodin. Un 
element qui s'appellerait <dateDePaiement> serait moins polymorphe car il garderait 
une bonne partie de son sens meme isole de son contexte. 

Polymorphisme 

Le polymorphisme concerne les messages envoyes aux objets : un meme message 
peut etre envoye a differents objets qui, en fonction de leur type, rendront des 
reponses differentes. En XML, le polymorphisme concerne les elements ayant un 
meme nom mais des types differents (c'est possible avec XML Schema). 

Publication module code 

Le code d'un module de publication est l'identifiant unique attribue a la structure 
d'assemblage d'une publication. En general, cet identifiant est egalement visible dans 
la publication finale. 

Reference 

Une reference est un identifiant permettant de connaitre la cible d'un lien. 

Reference d'entite 

En XML, une reference d'entite (on devrait dire reference a une entite) est un identi- 
fiant renvoyant a une declaration d'entite. 

Reification 

La reification est un concept relatif aux cartes de topiques. C'est l'instanciation phy- 
sique, concrete, d'une abstraction, en particulier un sujet. Quand on met un sujet 
dans un certain contexte, il devient un topique : on dit que le sujet est reifie. 
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Ressource 

Une ressource est toute information electronique accessible a partir d'une 
adresse URL. A ne pas confondre avec les memoires d'ordinateur, imprimantes et 
autres systemes physiques egalement appeles ressources dans le monde informatique. 

Schema conceptuel 

Voir modele conceptuel. 

Schema a base de grammaire 

Un schema a base de grammaire definit la syntaxe d'un vocabulaire XML en 
totalite : les noms des elements, des attributs, leur type, parfois leur contenu impose. 
Contrairement aux schemas a base de regies, ces schemas ne permettent pas aux 
documents XML d'etre partiellement valides. 

Voir aussi la rubrique Metamodele. 

Schema a base de regies 

Un schema a base de regies definit des regies que le document XML doit verifier et 
qui peuvent tout aussi bien porter sur la presence (un certain nombre de fois) d'un 
element que sur une correlation entre la valeur d'un attribut et le contenu d'un ele- 
ment. Contrairement aux schemas a base de grammaire, ces schemas permettent 
d'avoir des documents XML « partiellement » valides. Expliquons ce que Ton entend 
par partiellement valides : certes, toutes les regies edictees par le schema doivent etre 
verifiees, mais il n'est pas oblige que ces regies portent sur tous les elements du 
document XML. 

Voir aussi rubrique Metamodele. 
Schemas 

Voir la rubrique Modele vs schema, langage de modelisation. 

Schematron 

Langage d'ecriture de modele XML a base de regies. Les regies de Schematron sont 
ecrites principalement en s'appuyant sur le langage Xpath. 

Semantique 

La semantique est le sens profond d'un nom, par rapport a son contexte d'utilisation. 
La semantique des elements, de leurs attributs, represente le sens qu'ils ont par rap- 
port a l'application qui les utilise. Plus la semantique est precise et moins l'element 
est polymorphe. 
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Serialisation 

Le mot serialisation designe la transformation qui consiste a produire un fichier 
XML physique a partir de sa representation en memoire. XML est tel qu'il n'existe 
aujourd'hui pas une seule representation possible mais plusieurs. La serialisation con- 
siste a reproduire physiquement dans un fichier le sens de lecture d'un document 
XML en conservant les codes permettant de comprendre sa structure arborescente, 
ainsi que toutes les autres unites d'information autorisees. 

La serialisation est done la traduction d'un sens de parcours de l'arbre. Nous allons 
expliquer ce propos a l'aide de trois figures inspirees du livre de Ronald Bourret, 
Mapping DTDs to Databases, paru en 2000 aux editions O'Reilly 

II existe quatre manieres d'envisager le sens de parcours d'un arbre : 

• l'ordre defini par le ciblage des elements ; 

• l'ordre hierarchique ; 

• l'ordre du document ; 

• l'ordre des classes d'objets. 

Pour les illustrer, nous utiliserons le fragment suivant : 

<para>IDENTIFICATION BY CUSTOMER<custname>Ai r Canada</ 
custnamexcus>ACN</cusxxref ref i d="i bc001"x/para> 

L'ordre de ciblage correspond a la notion de fratrie, qui se definit comme etant 
l'ensemble des elements d'un meme niveau hierarchique. Pour le fragment prece- 
dent, cet ordre est illustre a la figure E-l. 

<para> 



Identification by... <custname> <cus> <xref> 

12 3 4 

Air Canada CAN 

5 6 

Figure E-1 Representation graphique de l'ordre des elements selon la regie du ciblage 



L'ordre hierarchique correspond a la profondeur des elements dans l'arborescence 
definie par la structure depuis la racine. Cet ordre est illustre a la figure E-2. 
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1 <para> 



I I I I 

2 Identification by... <custname> <cus> <xref> 

3 Air Canada ACN 

Figure E-2 Representation graphique de I'ordre des elements selon la regie hierarchique 

L'ordre du document est celui qui represente I'ordre des elements dans le sens de la 
lecture. Cet ordre est illustre a la figure E-3. 







<para> 










1 
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Identification by... 


| 
<custname> 




| 
<cus> 


<xref> 
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3 

Air Canada 
4 




5 

CAN 
6 


7 



Figure E-3 Representation graphique de I'ordre des elements selon la regie du document 

Dans les applications orientees objet telles que DOM (Document Object Model), la 
quatrieme maniere de parcourir une arborescence d'objets, c'est de cibler les objets 
d'une meme classe. Si les balises <para>, <custname> et <cus> representent trois 
sous-classes de la classe des elements et si Identification by ..., Ai r Canada et CAN 
representent trois noeuds de l'ensemble des noeuds textuels, on peut envisager de 
balayer cet ensemble d'objets en sautant de paragraphe en paragraphe, de lien en lien, 
de noeud textuel en noeud textuel, etc. Ce mode de lecture est notamment l'une des 
caracteristiques de XPath. Ce mode de parcours ne fait pas ici l'objet d'une illustra- 
tion car il ouvre la voie a autant de possibilites qu'il existe de classes d'objets dans un 
document XML, et car il n'est jamais utilise dans le but de stocker un 
document XML. 
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Serialise 

Un document XML est serialise lorsqu'il a ete enregistre physiquement. Quand les 
donnees sont stockees en memoire sous la forme d'un DOM (Document Object 
Model), la serialisation va de soi mais quand il s'agit d'objets, la serialisation est le 
resultat de la transformation des champs et proprietes publics d'un objet, ou les para- 
metres et valeurs de retour des methodes, en un flux XML conforme a un schema 
XML specifique. C'est typiquement ce qui se passe lors des operations de serialisa- 
tion de SOAP. 

Serveur de ressources 

La notion de serveur de ressource intervient lorsque les liens entre ressources sont 
definis logiquement, sans utilisation d'adresses physiques. Au moment de la resolu- 
tion du lien, il faut bien transposer l'identifiant logique en adresse physique. On y 
precede par programme ou par un serveur de ressources qui a la capacite de recevoir 
un identifiant logique et de retourner l'URL physique de la ressource correspondante. 

Source 

Dans notre ouvrage, la source designe toujours la source d'un lien ; a ne pas con- 
fondre done avec un code source. La source d'un lien est la ressource qui contient le 
point de depart de ce lien. 

Squelette de publication 

Un squelette de publication est une ossature ecrite en XML qui specifie les compo- 
sants d'une publication, leur ordre d'apparition, ainsi que les numeros de revision des 
composants utilises. 

Structure d'assemblage 

Voir squelette de publication. 

Superstructure UML 2.0 

II s'agit du deuxieme livre de la specification UML 2.0. Sur les bases des principes 
fondateurs definis dans le livre infrastructure UML 2.0, il definit l'ensemble des con- 
cepts de modelisation proposes par UML 2.0. 

Voir infrastructure UML 2.0 

Syntaxe abstraite 

On appelle syntaxe abstraite une syntaxe dans laquelle les caracteres specifiques sont 
remplaces par des variables. Ainsi, une telle syntaxe laisse la porte ouverte a plusieurs 
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implementations. Quand les variables sont remplacees par les caracteres definitifs, on 
obtient une syntaxe concrete. 

Syntaxe concrete 

Voir syntaxe abstraite. 

Systeme d' information 

Un systeme d'information represente l'ensemble des moyens humains et technique 
mis en ceuvre pour gerer les informations necessaires au fonctionnement d'une entre- 
prise. II couvre les grandes fonctions de creation, archivage, transformation et diffu- 
sion de l'information. A ce titre, il fait appel aux techniques informatiques de gestion 
des donnees, des traitements et des communications, ainsi qu'aux methodes de mise 
en ceuvre de ces techniques. 

Taxinomie 

Etude theorique des bases, lois, regies, principes d'une classification. Le terme est 
utilise pour designer des classifications de mots. 

Synonyme de taxonomie. 

Taxonomie 

Voir taxinomie. 

Topics Map 

Voir la rubrique carte de topiques. 

Topique 

Voir la rubrique carte de topiques. 

Type d'un element 

Le type d'un element est la definition de la nature de son contenu. En XML, le type 
peut etre simple, 1' element ne contenant qu'une chaine de caracteres, ou complexe 
quand 1' element renferme des sous elements et/ou des attributs. 

Les chaines de caracteres peuvent elles-memes etre de plusieurs types : dates, nom- 
bres, durees, booleens, etc. 

Parmi les types complexes, on trouve les types mixtes (texte et sous-elements meles) 
et vide (1' element ne contient rien). 
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Unite d' information 

Une unite d'information est un module. 

A ne pas confondre avec une unite ' documentaire, expression parfois utilisee pour desi- 
gner un ensemble de modules intermediate entre un module et une publication. 

Voir la rubrique module. 

Urbanisation 

L'urbanisation est une discipline de gestion des systemes d'information visant a ali- 
gner les fonctions requises par les divisions operationnelles de l'entreprise avec 
l'architecture logicielle et technique des systemes informatiques. L'objectif en est de 
definir les regies d'equilibre entre la dynamique requise par les processus toujours 
mouvants de l'entreprise et la necessaire structuration des donnees et des pro- 
grammes propre aux techniques de developpements informatiques. 

Validation de schema 

La validation de schema est une operation par laquelle un document XML est con- 
trole par rapport au schema qu'il est cense respecter. Quand le controle est positif, il 
est possible de produire un PSVI, ou Post Schema Validation Infoset, qui est un 
ensemble d'informations XML contenant la totalite de l'information : le document 
XML et son schema associe (attention, un PSVI n'est pas qu'une simple concatena- 
tion des deux mais une fusion). 

Validateur et parseur 

Un validateur est un programme dont le role est de controler la conformite d'un 
document XML par rapport a un schema. 

Un parseur - en francais analyseur lexico-syntaxique - est un programme qui a pour 
role de verifier la validite lexicale et syntaxique d'un document XML. 

A l'epoque ou seules les DTD existaient, le parseur controlait le vocabulaire, les carac- 
teres et les structures utilises dans un document XML. La tendance actuelle est d'avoir 
plusieurs types de validation : conformite d'un document XML par rapport a la recom- 
mandation XML Infoset, conformite par rapport a un ou plusieurs schema(s) . . . 

Le « parsing » ou analyse lexico-syntaxique, est le controle de la validite lexicale et 
syntaxique d'un document XML : les caracteres utilises dans le document XML 
sont-ils autorises ? la syntaxe XML est-elle respectee ? le document est-il bien 
forme ? 
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La validation, c'est le controle de la conformite d'un document XML par rapport a 
un schema. La validation peut aj outer des informations dans le document XML - 
par exemple, ajout des valeurs d'attributs par defaut - et en modifier le contenu - par 
exemple, ecriture homogene des nombres et suppression des blancs anormaux. 

Validation semantique 

La validation semantique consiste a controler que des elements, des attributs ou des 
valeurs de contenus sont utilises correctement par rapport a leur sens. 

La validation semantique s' applique aux documents XML comme aux langages 
d'ecriture de schemas. 

La semantique peut etre definie formellement - c'est le cas de RelaxNG via des 
regies d'inference -, ou par des explications en langage naturel - c'est le cas des 
schemas XML duW3C. 

Concernant les donnees, la semantique peut etre controlee par rapport a des the- 
saurus, des ontologies, voire des types. 

Vocabulaire (voir aussi grammaire) 

Un vocabulaire est l'ensemble des noms d'elements et d'attributs definis par un 
schema XML. 

Web semantique 

Le concept de Web semantique vise a faire prendre conscience de l'importance de la 
question du sens dans les pages web, et ce afin de pouvoir les retrouver et de donner 
une representation de ce sens qui soit exploitable par des agents logiciels. La simple 
recherche en plein texte ne suffit pas. Les pages web doivent etre classees, triees par 
theme, afin que les mots qu'elles contiennent aient du sens pour des requetes intelli- 
gentes. Quand on cherche a « contacter un avocat sur Paris », on n'est pas vraiment 
satisfait de tomber sur tous les marchands de primeur de la capitale ! 
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